在使用Go channel的时候,一个适用的原则是不要从接收端关闭channel,也不要在多个并发发送端中关闭channel。换句话说,如果sender(发送者)只是唯一的sender或者是channel最后一个活跃的sender,那么你应该在sender的goroutine关闭channel,从而通知receiver(s)(接收者们)已经没有值可以读了。维持这条原则将保证永远不会发生向一个已经关闭的channel发送值或者关闭一个已经关闭的channel。
(我们将会称上面的原则为channel closing principle)
保持channel closing principle的优雅方案
channel closing principle要求我们只能在发送端进行channel的关闭,对于日常遇到的可以归结为三类
1、m个receivers,一个sender.
2、一个receiver,n个sender
3、m个receivers,n个sender
1、m个receivers,一个sender
M个receivers,一个sender,sender通过关闭data channel说“不再发送”
这是最简单的场景了,就只是当sender不想再发送的时候让sender关闭data 来关闭channel:
1 package main 2 3 import ( 4 "time" 5 math/rand 6 sync 7 log 8 ) 9 10 func main() { 11 rand.Seed(time.Now().UnixNano()) 12 log.SetFlags(013 14 // ... 15 const MaxRandomNumber = 100000 16 const NumReceivers = 100 17 18 wgReceivers := sync.WaitGroup{} 19 wgReceivers.Add(NumReceivers) 20 21 22 dataCh := make(chan int,10023 24 the sender 25 go func() { 26 for { 27 if value := rand.Intn(MaxRandomNumber); value == 28 the only sender can close the channel safely. 29 close(dataCh) 30 return 31 } else { 32 dataCh <- value 33 } 34 } 35 }() 36 37 receivers 38 for i := 0; i < NumReceivers; i++39 go func() { 40 defer wgReceivers.Done() 41 42 receive values until dataCh is closed and 43 the value buffer queue of dataCh is empty. 44 for value := range dataCh { 45 log.Println(value) 46 47 }() 48 } 49 50 wgReceivers.Wait() 51 }
2、一个receiver,n个senders
一个receiver,N个sender,receiver通过关闭一个额外的signal channel说“请停止发送”
这种场景比上一个要复杂一点。我们不能让receiver关闭data channel,因为这么做将会打破channel closing principle。但是我们可以让receiver关闭一个额外的signal channel来通知sender停止发送值:
const NumSenders = 1000 19 wgReceivers.Add(123 stopCh := make(chan struct{}) 24 stopCh is an additional signal channel. 25 Its sender is the receiver of channel dataCh. Its reveivers are the senders of channel dataCh. 27 28 senders 29 0; i < NumSenders; i++30 31 32 value := rand.Intn(MaxRandomNumber) 33 34 select35 case <- stopCh: 36 37 case dataCh <- value: 38 } 41 42 43 the receiver 44 defer wgReceivers.Done() 46 47 48 if value == MaxRandomNumber-49 the receiver of the dataCh channel is 50 also the sender of the stopCh cahnnel. 51 It is safe to close the stop channel here. 52 close(stopCh) 53 54 55 56 log.Println(value) 57 58 59 60 61 62 }
3、m个receivers,n个sender
M个receiver,N个sender,它们当中任意一个通过通知一个moderator(仲裁者)关闭额外的signal channel来说“让我们结束游戏吧”
这是最复杂的场景了。我们不能让任意的receivers和senders关闭data channel,也不能让任何一个receivers通过关闭一个额外的signal channel来通知所有的senders和receivers退出游戏。这么做的话会打破channel closing principle。但是,我们可以引入一个moderator来关闭一个额外的signal channel。这个例子的一个技巧是怎么通知moderator去关闭额外的signal channel:
1 2 3 4 5 6 7 8 strconv 9 10 11 12 13 log.SetFlags( 14 15 16 17 10 18 19 20 wgReceivers := 21 22 23 24 dataCh := make(chan 25 stopCh := make(chan 26 27 Its sender is the moderator goroutine shown below. 28 Its reveivers are all senders and receivers of dataCh. 29 toStop := make(chan string,1)"> 30 the channel toStop is used to notify the moderator 31 to close the additional signal channel (stopCh). 32 Its senders are any senders and receivers of dataCh. 33 Its reveiver is the moderator goroutine shown below. 34 35 var stoppedBy string 36 37 moderator 38 39 stoppedBy = <- toStop part of the trick used to notify the moderator 40 to close the additional signal channel. 41 close(stopCh) 42 43 44 45 46 go func(id string) { 47 48 value := 49 if value == 50 here,a trick is used to notify the moderator 51 52 53 case toStop <- sender#" + id: 54 default: 55 } 56 57 58 59 the first select here is to try to exit the 60 goroutine as early as possible. 61 62 63 64 65 66 67 68 69 70 71 72 73 }(strconv.Itoa(i)) 74 75 76 77 78 go func(id 79 80 81 82 same as senders,the first select here is to 83 try to exit the goroutine as early as possible. 84 85 86 87 88 89 90 91 92 93 case value := <-dataCh: 94 95 the same trick is used to notify the moderator 96 97 98 receiver# 99 100 } 101 102 103 104 log.Println(value) 105 106 107 108 109 110 111 112 log.Println(stopped by",stoppedBy) 113 }
打破channel closing principle
有没有一个内置函数可以检查一个channel是否已经关闭。如果你能确定不会向channel发送任何值,那么也确实需要一个简单的方法来检查channel是否已经关闭:
3 import fmt 4 5 type T int 6 7 func IsClosed(ch <-chan T) bool 8 9 ch: 10 return true 11 12 false 15 } 16 17 18 c := make(chan T) 19 fmt.Println(IsClosed(c)) false 20 close(c) 21 fmt.Println(IsClosed(c)) true 22 }
上面已经提到了,没有一种适用的方式来检查channel是否已经关闭了。但是,就算有一个简单的 closed(chan T) bool
函数来检查channel是否已经关闭,它的用处还是很有限的,就像内置的len
函数用来检查缓冲channel中元素数量一样。原因就在于,已经检查过的channel的状态有可能在调用了类似的方法返回之后就修改了,因此返回来的值已经不能够反映刚才检查的channel的当前状态了。
尽管在调用closed(ch)
返回true
的情况下停止向channel发送值是可以的,但是如果调用closed(ch)
返回false
,那么关闭channel或者继续向channel发送值就不安全了(会panic)。
The Channel Closing Principle
在使用Go channel的时候,一个适用的原则是不要从接收端关闭channel,也不要在多个并发发送端中关闭channel。换句话说,如果sender(发送者)只是唯一的sender或者是channel最后一个活跃的sender,那么你应该在sender的goroutine关闭channel,从而通知receiver(s)(接收者们)已经没有值可以读了。维持这条原则将保证永远不会发生向一个已经关闭的channel发送值或者关闭一个已经关闭的channel。
(下面,我们将会称上面的原则为channel closing principle
打破channel closing principle的解决方案
如果你因为某种原因从接收端(receiver side)关闭channel或者在多个发送者中的一个关闭channel,那么你应该使用列在Golang panic/recover Use Cases的函数来安全地发送值到channel中(假设channel的元素类型是T)
1 func SafeSend(ch chan T,value T) (closed 2 defer func() { 3 if recover() != nil { 4 the return result can be altered 5 in a defer function call 6 closed = 7 10 ch <- value panic if ch is closed false <=> closed = false; return 12 }
如果channel ch
没有被关闭的话,那么这个函数的性能将和ch <- value
接近。对于channel关闭的时候,SafeSend
函数只会在每个sender goroutine中调用一次,因此程序不会有太大的性能损失。
同样的想法也可以用在从多个goroutine关闭channel中:
1 func SafeClose(ch chan T) (justClosed 4 justClosed = 5 6 7 assume ch != nil here. 9 close(ch) 10 11 }
很多人喜欢用sync.Once
来关闭channel:
1 type MyChannel C chan T once sync.Once 4 5 6 func NewMyChannel() *MyChannel { 7 return &MyChannel{C: make(chan T)} 10 func (mc *MyChannel) SafeClose() { mc.once.Do(func(){ close(mc.C) 13 }) 14 }
当然了,我们也可以用sync.Mutex
来避免多次关闭channel:
C chan T 3 closed bool mutex sync.Mutex 7 func NewMyChannel() * 9 10 11 func (mc * mc.mutex.Lock() 13 if !mc.closed { 14 15 mc.closed = 16 mc.mutex.Unlock() 18 19 20 func (mc *MyChannel) IsClosed() 21 22 defer mc.mutex.Unlock() 23 return mc.closed 24 }
我们应该要理解为什么Go不支持内置SafeSend
和SafeClose
函数,原因就在于并不推荐从接收端或者多个并发发送端关闭channel。Golang甚至禁止关闭只接收(receive-only)的channel。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。