如何优雅的关闭channel?
一、channel使用存在的不方便地方
1、在不改变channel自身状态的情况下,无法获知一个channnel是否关闭。
2、关闭一个已经关闭的channel,会导致panic。因此,如果关闭channel的一方在不知道channel是否关闭状态时就去贸然关闭channel是件很危险的事。
3、向一个已经关闭的channel发送数据会导致panic。因此,如果向channel发送数据的一方不知道channel是否处于关闭状态就贸然向channel发送数据是很危险的事情。
一个比较粗糙的检查channel是否关闭的函数:
func IsClosed(ch <-chan interface{}) bool {
select {
case <-ch:
return true
default:
}
return false
}
func main() {
c := make(chan interface{})
fmt.Println(IsClosed(c)) // false
close(c)
fmt.Println(IsClosed(c)) // true
}
上面的代码其实存在很多问题。
首先,IsClosed函数是一个有副作用的函数。每调用一次,都会读出channel里面的一个元素,改变了channel的状态,这不是一个好函数,干活就干活,还顺手牵羊?
其次,IsClosed函数返回的结果仅代表调用时候的那个瞬间,并不能保证调用之后不会有其他goroutine对这个channel进行了一些操作,改变了这个channel的状态。比如:IsClosed函数返回true,但这时有另外一个goroutine关闭了这个channel,这时候我们就会拿着这个过时的"channel未关闭"信息,向其发送数据,就会导致panic的发生。
当然,一个channel不会被重复关闭两次,如果IsClosed函数返回的结果是true,说明channel是真的关闭了。
有一句广泛流传的关闭channel的原则:
不要从一个 receiver 侧关闭 channel,也不要在有多个 sender 时,关闭 channel。
向channel发送元素的就是sender,因此sender可以决定何时不发送数据,并且关闭channel。但是如果有多个sender,某个sender同样没法确定其他sender的情况。这时候也不能贸然的关闭channel。
有两个不优雅关闭channel的方法:
1、使用defer-recover机制,放心大胆地关闭channel或者向channel发送数据,即使发生了panic,有defer-recover在兜底。
2、使用sync.Once来保证只关闭一次。
二、如何优雅关闭channel
根据sender和receiver的个数,可以分为以下几种情况:
1、一个sender,一个receiver
2、一个sender,M个receiver
3、N个sender,一个receiver
4、N个sender,M个receiver
对于1,2这两种情况,只有一个sender,直接从sender段关闭就好。
第3种情形下,优雅关闭channel的方法是:唯一的receiver发出一个关闭channel的信号,senders监听到关闭信号后,停止发送数据。
func main() {
rand.Seed(time.Now().UnixNano())
const Max = 10000
const NumSenders = 1000
dataChan := make(chan int, 100)
stopChan := make(chan struct{})
// senders
for i := 0; i < NumSenders; i++ {
go func() {
for {
select {
// 监听关闭channel的信号,退出
case <-stopChan:
return
// 给dataChan中发送数据
case dataChan <- rand.Intn(Max):
}
}
}()
}
// receiver
go func() {
// 从dataChan中遍历数据
for value := range dataChan {
// 如果value的值为9999,通知sender停止发送数据
if value == Max-1 {
fmt.Println("send stop signal to senders.")
close(stopChan)
return
}
fmt.Println(value)
}
}()
select {
// 阻塞一小时退出
case <-time.After(time.Hour):
}
}
这里的stopCh就是信号channel,它本身只有一个sender,因此可以直接关闭它。senders收到了关闭信号后,select分支case<-stopCh
被选中,退出函数,不再发送数据。
需要说明的是,上面的代码并没有明确关闭dataCh。在Go语言中,对于一个channel,如果最终没有任何goroutine引用它,不管channel有没有被关闭,最终都会被GC回收。所以在这种情形下,所谓的优雅地关闭channel就是不关闭channel,让GC代劳。
最后一种情况,优雅关闭channel的方法是:any one of them says “let’s end the game” by notifying a moderator to close an additional signal channel。
和第三种情况不同,这里有M个receiver,如果,采用第3种解决方案,由receiver直接关闭stopCh的话,就会重复关闭一个channel,导致panic。因此需要增加一个中间人,M个receiver都向它发送关闭dataCh的"请求",中间人收到第一个请求后,就会直接下达关闭dataCh的指令(通过关闭stopCh,这时就不会发生重复关闭的情况,因为stopCh的发送方只有中间人一个)。另外这里N个sender也可以向中间人发送关闭dataCh的请求。
func main() {
rand.Seed(time.Now().UnixNano())
const Max = 10000
const NumReceivers = 10
const NumSenders = 1000
dataCh := make(chan int, 100)
stopCh := make(chan struct{})
// 这里必须是一个有缓冲的channel
toStop := make(chan string, 1)
var stoppedBy string
// 中间人
go func() {
// 接收到了关闭channel的请求
stoppedBy = <-toStop
// 发送关闭dataCh的信号
close(stopCh)
}()
// senders
for i := 0; i < NumSenders; i++ {
go func(id string) {
for {
value := rand.Intn(Max)
// 如果value=0,则给中间人发送关闭channel的信号
if value == 0 {
select {
case toStop <- "sender#" + id:
// 此处是为了防止toStop这个channel阻塞
default:
}
return
}
select {
// 监听关闭channel的信号
case <-stopCh:
return
case dataCh <- value:
}
}
}(strconv.Itoa(i))
}
// receivers
for i := 0; i < NumReceivers; i++ {
go func(id string) {
for {
select {
// 监听关闭信号,退出,停止接收数据
case <-stopCh:
return
// 接收数据
case value := <-dataCh:
// 如果接收到了9999,则给中间人发送关闭channel的信号
if value == Max-1 {
select {
case toStop <- "receiver#" + id:
default:
}
return
}
fmt.Println(value)
}
}
}(strconv.Itoa(i))
}
select {
case <-time.After(time.Hour):
}
}
代码里toStop就是中间人的角色,使用它来接收senders和receivers发送过来的关闭dataCh请求。
这里将toStop声明成了一个缓冲型的channel。假设toStop声明的是一个非缓冲型的channel,那么第一个发送的关闭dataCh请求可能会丢失。因为无论是sender还是receiver都是通过select语句来发送请求,如果中间人所在的goroutine没有准备好,那么select语句就不会被选中,直接走default选项了,什么都不做。这样,第一个关闭dataCh的请求就会丢失。
如果把toStop的容量声明成Num(senders) + Num(receivers),那么发送dataCh请求的部分可以改写成更简洁的形式:
func main() {
rand.Seed(time.Now().UnixNano())
const Max = 10000
const NumReceivers = 10
const NumSenders = 1000
dataCh := make(chan int, 100)
stopCh := make(chan struct{})
// 这里必须是一个有缓冲的channel
toStop := make(chan string, NumSenders+NumReceivers)
var stoppedBy string
// 中间人
go func() {
// 接收到了关闭channel的请求
stoppedBy = <-toStop
// 发送关闭dataCh的信号
close(stopCh)
}()
// senders
for i := 0; i < NumSenders; i++ {
go func(id string) {
for {
value := rand.Intn(Max)
// 如果value=0,则给中间人发送关闭channel的信号
if value == 0 {
toStop <- "sender#" + id
return
}
select {
// 监听关闭channel的信号
case <-stopCh:
return
case dataCh <- value:
}
}
}(strconv.Itoa(i))
}
// receivers
for i := 0; i < NumReceivers; i++ {
go func(id string) {
for {
select {
// 监听关闭信号,退出,停止接收数据
case <-stopCh:
return
// 接收数据
case value := <-dataCh:
// 如果接收到了9999,则给中间人发送关闭channel的信号
if value == Max-1 {
toStop <- "receiver#" + id
return
}
fmt.Println(value)
}
}
}(strconv.Itoa(i))
}
select {
case <-time.After(time.Hour):
}
}
直接向toStop发送请求,因为toStop容量足够大,所以不用担心阻塞,自然也就不用select语句再加一个default case来避免阻塞。
可以看到,这里同样没有真正关闭dataCh,同第3种情况。
参考链接: