本文主要是介绍由浅入深聊聊Golang中select的实现机制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
正文
话说今天在玩select的时候发现一个问题,是这样的:
片段1:
func main(){var count intfor {select {case <-time.Tick(time.Millisecond * 500):fmt.Println("咖啡色的羊驼")count++fmt.Println("count--->" , count)case <-time.Tick(time.Millisecond * 499) :fmt.Println(time.Now().Unix())count++fmt.Println("count--->" , count)}}
}
片段2:
func main(){t1 := time.Tick(time.Second)t2 := time.Tick(time.Second)var count intfor {select {case <-t1:fmt.Println("咖啡色的羊驼")count++fmt.Println("count--->" , count)case <-t2 :fmt.Println(time.Now().Unix())count++fmt.Println("count--->" , count)}}
}
两个问题:
1.以上片段的输出结果是?
2.如何解释?
第一个问题好解决,跑一下就是,很明显输出结果肯定不同。
片段1:
1535673600
count---> 1
1535673600
count---> 2
1535673601
count---> 3
片段2:
咖啡色的羊驼
count---> 1
1535673600
count---> 2
咖啡色的羊驼
count---> 3
1535673601
count---> 4
第二个好理解,因为select监听了两个time的通道,所以交替出现。
那么第一个为何只有出现1个?
为了这个问题不得不把select的实现机制走一波,所以有了此文。
select机制简述
select有这么几个需要关注的机制
1.select+case是用于阻塞监听goroutine的,如果没有case,就单单一个select{},则为监听当前程序中的goroutine,此时注意,需要有真实的goroutine在跑,否则select{}会报panic
2.select底下有多个可执行的case,则随机执行一个。
3.select常配合for循环来监听channel有没有故事发生。需要注意的是在这个场景下,break只是退出当前select而不会退出for,需要用break TIP / goto的方式。
4.无缓冲的通道,则传值后立马close,则会在close之前阻塞,有缓冲的通道则即使close了也会继续让接收后面的值
5.同个通道多个goroutine进行关闭,可用recover panic的方式来判断通道关闭问题
看完以上知识点其实还是没法解释本文的核心疑惑,继续往下!
select机制详解
select的机制可以查看/src/runtime/select.go来了解。
源码片段解读:
func selectgo(sel *hselect) int {// ...// case洗牌pollslice := slice{unsafe.Pointer(sel.pollorder), int(sel.ncase), int(sel.ncase)}pollorder := *(*[]uint16)(unsafe.Pointer(&pollslice))for i := 1; i < int(sel.ncase); i++ {//....}// 给case排序lockslice := slice{unsafe.Pointer(sel.lockorder), int(sel.ncase), int(sel.ncase)}lockorder := *(*[]uint16)(unsafe.Pointer(&lockslice))for i := 0; i < int(sel.ncase); i++ {// ...}for i := int(sel.ncase) - 1; i >= 0; i-- {// ...}// 加锁该select中所有的channelsellock(scases, lockorder)// 进入loop
loop:// ... // pass 1 - look for something already waiting// 按顺序遍历case来寻找可执行的casefor i := 0; i < int(sel.ncase); i++ {//...switch cas.kind {case caseNil:continuecase caseRecv:// ... goto xxxcase caseSend:// ... goto xxxcase caseDefault:dfli = casidfl = cas}}// 没有找到可以执行的case,但有default条件,这个if里就会直接退出了。if dfl != nil {// ...}// ...// pass 2 - enqueue on all chans// chan入等待队列for _, casei := range lockorder {// ...switch cas.kind {case caseRecv:c.recvq.enqueue(sg)case caseSend:c.sendq.enqueue(sg)}}// wait for someone to wake us up// 等待被唤起,同时解锁channel(selparkcommit这里实现的)gp.param = nilgopark(selparkcommit, nil, "select", traceEvGoBlockSelect, 1)// 突然有故事发生,被唤醒,再次该select下全部channel加锁sellock(scases, lockorder)// pass 3 - dequeue from unsuccessful chans// 本轮最后一次循环操作,获取可执行case,其余全部出队列丢弃casi = -1cas = nilsglist = gp.waiting// Clear all elem before unlinking from gp.waiting.for sg1 := gp.waiting; sg1 != nil; sg1 = sg1.waitlink {sg1.isSelect = falsesg1.elem = nilsg1.c = nil}gp.waiting = nilfor _, casei := range lockorder {// ...if sg == sglist {// sg has already been dequeued by the G that woke us up.casi = int(casei)cas = k} else {c = k.cif k.kind == caseSend {c.sendq.dequeueSudoG(sglist)} else {c.recvq.dequeueSudoG(sglist)}}// ...}// 没有的话,再走一次loopif cas == nil {goto loop}// ...
bufrecv:// can receive from buffer
bufsend:// ...
recv:// ...
rclose:// ...
send:// ...
retc:// ...
sclose:// send on closed channel
}
为了方便展示,专门搞了一张很丑的图,来说明流程:
大概就是说呢,select是分四步进行的。
本文的疑惑关键点就在于那个loop的时候,当接收到发现一个可执行的时候,本次select不会执行的那些case对应的channel给出队当前goroutine,就不管他们了,就丢了,由于time.Tick是现场在case里头创建的,而不是像片段二是处于全局栈中,所以当每次任何一个执行的时候,另一个就被抛弃了,再次selelct的时候有需要重新获取,又是新的需要重头再来。
本人暂时的理解是这样,如果你有更好的理解,请给我留言,谢谢。
如果你觉得有收获~可以关注我的公众号【咖啡色的羊驼】~第一时间收到我的分享和知识梳理~
这篇关于由浅入深聊聊Golang中select的实现机制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!