开发者社区> 技术小能手> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

如何优雅地关闭Go channel

简介:
+关注继续查看

几天前,我写了一篇文章来说明golang中channel的使用规范。在reddit和HN,那篇文章收到了很多赞同,但是我也收到了下面几个关于Go channel设计和规范的批评:

● 在不能更改channel状态的情况下,没有简单普遍的方式来检查channel是否已经关闭了
● 关闭已经关闭的channel会导致panic,所以在closer(关闭者)不知道channel是否已经关闭的情况下去关闭channel是很危险的
● 发送值到已经关闭的channel会导致panic,所以如果sender(发送者)在不知道channel是否已经关闭的情况下去向channel发送值是很危险的

那些批评看起来都很有道理(实际上并没有)。是的,没有一个内置函数可以检查一个channel是否已经关闭。如果你能确定不会向channel发送任何值,那么也确实需要一个简单的方法来检查channel是否已经关闭:


1package main
2
3import "fmt"
4
5type T int
6
7func IsClosed(ch <-chan T) bool {
8 select {
9 case <-ch:
10 return true
11 default:
12 }
13
14 return false
15}
16
17func main() {
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)


1func SafeSend(ch chan T, value T) (closed bool) {
2 defer func() {
3 if recover() != nil {
4 // the return result can be altered
5 // in a defer function call
6 closed = true
7 }
8 }()
9
10 ch <- value // panic if ch is closed
11 return false // <=> closed = false; return
12}

如果channel ch没有被关闭的话,那么这个函数的性能将和ch <- value接近。对于channel关闭的时候,SafeSend函数只会在每个sender goroutine中调用一次,因此程序不会有太大的性能损失。
同样的想法也可以用在从多个goroutine关闭channel中:


1func SafeClose(ch chan T) (justClosed bool) {
2 defer func() {
3 if recover() != nil {
4 justClosed = false
5 }
6 }()
7
8 // assume ch != nil here.
9 close(ch) // panic if ch is closed
10 return true
11}

很多人喜欢用sync.Once来关闭channel:


1type MyChannel struct {
2 C chan T
3 once sync.Once
4}
5
6func NewMyChannel() *MyChannel {
7 return &MyChannel{C: make(chan T)}
8}
9
10func (mc *MyChannel) SafeClose() {
11 mc.once.Do(func(){
12 close(mc.C)
13 })
14}

当然了,我们也可以用sync.Mutex来避免多次关闭channel:


1type MyChannel struct {
2 C chan T
3 closed bool
4 mutex sync.Mutex
5}
6
7func NewMyChannel() *MyChannel {
8 return &MyChannel{C: make(chan T)}
9}
10
11func (mc *MyChannel) SafeClose() {
12 mc.mutex.Lock()
13 if !mc.closed {
14 close(mc.C)
15 mc.closed = true
16 }
17 mc.mutex.Unlock()
18}
19
20func (mc *MyChannel) IsClosed() bool {
21 mc.mutex.Lock()
22 defer mc.mutex.Unlock()
23 return mc.closed
24}

我们应该要理解为什么Go不支持内置SafeSendSafeClose函数,原因就在于并不推荐从接收端或者多个并发发送端关闭channel。Golang甚至禁止关闭只接收(receive-only)的channel。

保持channel closing principle的优雅方案

上面的SaveSend函数有一个缺点是,在select语句的case关键字后不能作为发送操作被调用(译者注:类似于 case SafeSend(ch, t):)。另外一个缺点是,很多人,包括我自己都觉得上面通过使用panic/recoversync包的方案不够优雅。针对各种场景,下面介绍不用使用panic/recoversync包,纯粹是利用channel的解决方案。
(在下面的例子总,sync.WaitGroup只是用来让例子完整的。它的使用在实践中不一定一直都有用)

● M个receivers,一个sender,sender通过关闭data channel说“不再发送”
这是最简单的场景了,就只是当sender不想再发送的时候让sender关闭data 来关闭channel:

1package main
2
3import (
4 "time"
5 "math/rand"
6 "sync"
7 "log"
8)
9
10func main() {
11 rand.Seed(time.Now().UnixNano())
12 log.SetFlags(0)
13
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, 100)
23
24 // the sender
25 go func() {
26 for {
27 if value := rand.Intn(MaxRandomNumber); value == 0 {
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}
● 一个receiver,N个sender,receiver通过关闭一个额外的signal channel说“请停止发送”
这种场景比上一个要复杂一点。我们不能让receiver关闭data channel,因为这么做将会打破channel closing principle。但是我们可以让receiver关闭一个额外的signal channel来通知sender停止发送值:

1package main
2
3import (
4 "time"
5 "math/rand"
6 "sync"
7 "log"
8)
9
10func main() {
11 rand.Seed(time.Now().UnixNano())
12 log.SetFlags(0)
13
14 // ...
15 const MaxRandomNumber = 100000
16 const NumSenders = 1000
17
18 wgReceivers := sync.WaitGroup{}
19 wgReceivers.Add(1)
20
21 // ...
22 dataCh := make(chan int, 100)
23 stopCh := make(chan struct{})
24 // stopCh is an additional signal channel.
25 // Its sender is the receiver of channel dataCh.
26 // Its reveivers are the senders of channel dataCh.
27
28 // senders
29 for i := 0; i < NumSenders; i++ {
30 go func() {
31 for {
32 value := rand.Intn(MaxRandomNumber)
33
34 select {
35 case <- stopCh:
36 return
37 case dataCh <- value:
38 }
39 }
40 }()
41 }
42
43 // the receiver
44 go func() {
45 defer wgReceivers.Done()
46
47 for value := range dataCh {
48 if value == MaxRandomNumber-1 {
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 return
54 }
55
56 log.Println(value)
57 }
58 }()
59
60 // ...
61 wgReceivers.Wait()
62}

正如注释说的,对于额外的signal channel来说,它的sender是data channel的receiver。这个额外的signal channel被它唯一的sender关闭,遵守了channel closing principle

● 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:

1package main
2
3import (
4 "time"
5 "math/rand"
6 "sync"
7 "log"
8 "strconv"
9)
10
11func main() {
12 rand.Seed(time.Now().UnixNano())
13 log.SetFlags(0)
14
15 // ...
16 const MaxRandomNumber = 100000
17 const NumReceivers = 10
18 const NumSenders = 1000
19
20 wgReceivers := sync.WaitGroup{}
21 wgReceivers.Add(NumReceivers)
22
23 // ...
24 dataCh := make(chan int, 100)
25 stopCh := make(chan struct{})
26 // stopCh is an additional signal channel.
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 go func() {
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 // senders
45 for i := 0; i < NumSenders; i++ {
46 go func(id string) {
47 for {
48 value := rand.Intn(MaxRandomNumber)
49 if value == 0 {
50 // here, a trick is used to notify the moderator
51 // to close the additional signal channel.
52 select {
53 case toStop <- "sender#" + id:
54 default:
55 }
56 return
57 }
58
59 // the first select here is to try to exit the
60 // goroutine as early as possible.
61 select {
62 case <- stopCh:
63 return
64 default:
65 }
66
67 select {
68 case <- stopCh:
69 return
70 case dataCh <- value:
71 }
72 }
73 }(strconv.Itoa(i))
74 }
75
76 // receivers
77 for i := 0; i < NumReceivers; i++ {
78 go func(id string) {
79 defer wgReceivers.Done()
80
81 for {
82 // same as senders, the first select here is to
83 // try to exit the goroutine as early as possible.
84 select {
85 case <- stopCh:
86 return
87 default:
88 }
89
90 select {
91 case <- stopCh:
92 return
93 case value := <-dataCh:
94 if value == MaxRandomNumber-1 {
95 // the same trick is used to notify the moderator
96 // to close the additional signal channel.
97 select {
98 case toStop <- "receiver#" + id:
99 default:
100 }
101 return
102 }
103
104 log.Println(value)
105 }
106 }
107 }(strconv.Itoa(i))
108 }
109
110 // ...
111 wgReceivers.Wait()
112 log.Println("stopped by", stoppedBy)
113}

在这个例子中,仍然遵守着channel closing principle
请注意channel toStop的缓冲大小是1.这是为了避免当mederator goroutine 准备好之前第一个通知就已经发送了,导致丢失。

● 更多的场景?
很多的场景变体是基于上面三种的。举个例子,一个基于最复杂情况的变体可能要求receivers读取buffer channel中剩下所有的值。这应该很容易处理,所有这篇文章也就不提了。
尽管上面三种场景不能覆盖所有Go channel的使用场景,但它们是最基础的,实践中的大多数场景都可以分类到那三种中。

结论

这里没有一种场景要求你去打破channel closing principle。如果你遇到了这种场景,请思考一下你的设计并重写你的代码。
用Go编程就像在创作艺术。


原文发布时间为:2018-09-9

本文作者:天唯

本文来自云栖社区合作伙伴“Golang语言社区”,了解相关信息可以关注“Golang语言社区”。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
dotweb——go语言的一个微型web框架(三)路由注册
上一章我们讲了如何启动一个dotweb程序,本篇文章将介绍如何注册路由。 router是dotweb用来管理路由的结构体,它提供了一些关于路由操作函数。 app := dotweb.New() router := app.HttpServer.Router() 在上一篇文章中我们讲了dotweb.New()的用处,HttpServer负责处理请求,管理路由、session、中间件等等功能。
982 0
go语言学习与面向对象再思考
据说Smalltalk发明者Alan Kay就曾经说过: 我发明了面向对象,而我可以告诉你C++并不是我头脑里所想的东西. 面向对象的困惑 计算机里面只有数据和算法,数据用于对现实世界抽象建模,算法对数据演算,这已经很好,怎么出来一个面向对象这个"怪胎". 面向对象教学每次都要从对现实世
1910 0
+关注
技术小能手
云栖运营小编~
7194
文章
9
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载