Golang中select機制的案例分析

這篇文章主要介紹了Golang中select機制的案例分析，具有一定借鑒價值，需要的朋友可以參考下。希望大家閱讀完這篇文章后大有收獲。下面讓小編帶著大家一起了解一下。

正文

話說今天在玩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的時候有需要重新獲取，又是新的需要重頭再來。

感謝你能夠認真閱讀完這篇文章，希望小編分享Golang中select機制的案例分析內容對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，遇到問題就找億速云，詳細的解決方法等著你來學習!