Golang并发模型:select进阶
最近公司工作有点多,Golang的select进阶就这样被拖沓啦,今天坚持把时间挤一挤,把吹的牛皮补上。
前一篇文章《Golang并发模型:轻松入门select》介绍了select的作用和它的基本用法,这次介绍它的3个进阶特性。
nil
的通道永远阻塞- 如何跳出
for-select
select{}
阻塞
nil
的通道永远阻塞
当case
上读一个通道时,如果这个通道是nil
,则该case
永远阻塞。这个功能有1个妙用,select
通常处理的是多个通道,当某个读通道关闭了,但不想select
再继续关注此case
,继续处理其他case
,把该通道设置为nil
即可。
下面是一个合并程序等待两个输入通道都关闭后才退出的例子,就使用了这个特性。
func combine(inCh1, inCh2 <-chan int) <-chan int { // 输出通道 out := make(chan int) // 启动协程合并数据 go func() { defer close(out) for { select { case x, open := <-inCh1: if !open { inCh1 = nil continue } out<-x case x, open := <-inCh2: if !open { inCh2 = nil continue } out<-x } // 当ch1和ch2都关闭是才退出 if inCh1 == nil && inCh2 == nil { break } } }() return out }
如何跳出for-select
break
在select
内的并不能跳出for-select
循环。看下面的例子,consume
函数从通道inCh
不停读数据,期待在inCh
关闭后退出for-select
循环,但结果是永远没有退出。
func consume(inCh <-chan int) { i := 0 for { fmt.Printf("for: %d\n", i) select { case x, open := <-inCh: if !open { break } fmt.Printf("read: %d\n", x) } i++ } fmt.Println("combine-routine exit") }
运行结果:
➜ go run x.go for: 0 read: 0 for: 1 read: 1 for: 2 read: 2 for: 3 gen exit for: 4 for: 5 for: 6 for: 7 for: 8 ... // never stop
既然break
不能跳出for-select
,那怎么办呢?给你3个锦囊:
- 在满足条件的
case
内,使用return
,如果有结尾工作,尝试交给defer
。 - 在
select
外for
内使用break
挑出循环,如combine
函数。 - 使用
goto
。
select{}
永远阻塞
select{}
的效果等价于创建了1个通道,直接从通道读数据:
ch := make(chan int) <-ch
但是,这个写起来多麻烦啊!没select{}
简洁啊。
但是,永远阻塞能有什么用呢!?
当你开发一个并发程序的时候,main
函数千万不能在子协程干完活前退出啊,不然所有的协程都被迫退出了,还怎么提供服务呢?
比如,写了个Web服务程序,端口监听、后端处理等等都在子协程跑起来了,main
函数这时候能退出吗?
select应用场景
最后,介绍下我常用的select
场景:
- 无阻塞的读、写通道。即使通道是带缓存的,也是存在阻塞的情况,使用select可以完美的解决阻塞读写,这篇文章我之前发在了个人博客,后面给大家介绍下。
- 给某个请求/处理/操作,设置超时时间,一旦超时时间内无法完成,则停止处理。
select
本色:多通道处理
并发系列文章推荐
- 如果这篇文章对你有帮助,请点个赞/喜欢,鼓励我持续分享,感谢。
- 我的文章列表,点此可查看
- 如果喜欢本文,随意转载,但请保留此原文链接。
相关推荐
专注前端开发 2020-10-21
苏康申 2020-11-13
vitasfly 2020-11-12
oraclemch 2020-11-06
liuyang000 2020-09-25
FellowYourHeart 2020-10-05
赵继业 2020-08-17
whyname 2020-08-16
Seandba 2020-08-16
dbasunny 2020-08-16
拼命工作好好玩 2020-08-15
langyue 2020-08-15
写程序的赵童鞋 2020-08-03
Accpcjg 2020-08-02
tydldd 2020-07-30
好记忆也需烂 2020-07-28
jianghero 2020-07-28