#正文
话说今天在玩select的时候发现一个问题，是这样的：
片段1：
func main(){
var count int
for {
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 int
for {
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中所有的channel
sellock(scases, lockorder)
// 进入loop
loop:
// ...
// pass 1 - look for something already waiting
// 按顺序遍历case来寻找可执行的case
for i := 0; i < int(sel.ncase); i++ {
//...
switch cas.kind {
case caseNil:
continue
case caseRecv:
// ... goto xxx
case caseSend:
// ... goto xxx
case caseDefault:
dfli = casi
dfl = 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 = nil
gopark(selparkcommit, nil, "select", traceEvGoBlockSelect, 1)
// 突然有故事发生，被唤醒，再次该select下全部channel加锁
sellock(scases, lockorder)
// pass 3 - dequeue from unsuccessful chans
// 本轮最后一次循环操作，获取可执行case，其余全部出队列丢弃
casi = -1
cas = nil
sglist = gp.waiting
// Clear all elem before unlinking from gp.waiting.
for sg1 := gp.waiting; sg1 != nil; sg1 = sg1.waitlink {
sg1.isSelect = false
sg1.elem = nil
sg1.c = nil
}
gp.waiting = nil
for _, 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.c
if k.kind == caseSend {
c.sendq.dequeueSudoG(sglist)
} else {
c.recvq.dequeueSudoG(sglist)
}
}
// ...
}
// 没有的话，再走一次loop
if 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的时候有需要重新获取，又是新的需要重头再来。
本人暂时的理解是这样，如果你有更好的理解，请给我留言，谢谢。
有疑问加站长微信联系（非本文作者）
