話說今天在玩select的時候發現一個問題,是這樣的:bash
片斷1:oop
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:ui
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.如何解釋?spa
第一個問題好解決,跑一下就是,很明顯輸出結果確定不一樣。 片斷1:3d
1535673600
count---> 1
1535673600
count---> 2
1535673601
count---> 3
複製代碼
片斷2:code
咖啡色的羊駝
count---> 1
1535673600
count---> 2
咖啡色的羊駝
count---> 3
1535673601
count---> 4
複製代碼
第二個好理解,由於select監聽了兩個time的通道,因此交替出現。 那麼第一個爲什麼只有出現1個? 爲了這個問題不得不把select的實現機制走一波,因此有了此文。cdn
select有這麼幾個須要關注的機制 1.select+case是用於阻塞監聽goroutine的,若是沒有case,就單單一個select{},則爲監聽當前程序中的goroutine,此時注意,須要有真實的goroutine在跑,不然select{}會報panicblog
2.select底下有多個可執行的case,則隨機執行一個。排序
3.select常配合for循環來監聽channel有沒有故事發生。須要注意的是在這個場景下,break只是退出當前select而不會退出for,須要用break TIP / goto的方式。隊列
4.無緩衝的通道,則傳值後立馬close,則會在close以前阻塞,有緩衝的通道則即便close了也會繼續讓接收後面的值
5.同個通道多個goroutine進行關閉,可用recover panic的方式來判斷通道關閉問題
看完以上知識點其實仍是無法解釋本文的核心疑惑,繼續往下!
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的時候有須要從新獲取,又是新的須要重頭再來。
本人暫時的理解是這樣,若是你有更好的理解,請給我留言,謝謝。