嗯，你覺得 Go 在什么時候會搶占 P？
本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。
大家好，我是煎魚。
昨天剛從長沙浪完回來，準備 ”瀟瀟灑灑“ 寫一篇游記，分享一波美食+游記，有五一準備去長沙玩的小伙伴嗎?
前幾天我們有聊到《單核 CPU，開兩個 Goroutine，其中一個死循環，會怎么樣?》的問題，我們在一個細節部分有提到：
有新的小伙伴會產生更多的疑問，那就是在 Go 語言中，是如何搶占 P 的呢，這里面是怎么做的?
今天這篇文章我們就來解密搶占 P。
調度器的發展史
在 Go 語言中，Goroutine 早期是沒有設計成搶占式的，早期 Goroutine 只有讀寫、主動讓出、鎖等操作時才會觸發調度切換。
這樣有一個嚴重的問題，就是垃圾回收器進行 STW 時，如果有一個 Goroutine 一直都在阻塞調用，垃圾回收器就會一直等待他，不知道等到什么時候...
這種情況下就需要搶占式調度來解決問題。如果一個 Goroutine 運行時間過久，就需要進行搶占來解決。
這塊 Go 語言在 Go1.2 起開始實現搶占式調度器，不斷完善直至今日：
- Go0.x：基于單線程的程調度器。
- Go1.0：基于多線程的調度器。
- Go1.1：基于任務竊取的調度器。
- Go1.2 - Go1.13：基于協作的搶占式調度器。
- Go1.14：基于信號的搶占式調度器。
調度器的新提案：非均勻存儲器訪問調度(Non-uniform memory access，NUMA)， 但由于實現過于復雜，優先級也不夠高，因此遲遲未提上日程。
有興趣的小伙伴可以詳見 Dmitry Vyukov, dvyukov 所提出的 NUMA-aware scheduler for Go。
為什么要搶占 P
為什么會要想去搶占 P 呢，說白了就是不搶，就沒機會運行，會 hang 死。又或是資源分配不均了，
這在調度器設計中顯然是不合理的。
跟這個例子一樣：
- // Main Goroutine
- func main() {
- // 模擬單核 CPU
- runtime.GOMAXPROCS(1)
- // 模擬 Goroutine 死循環
- go func() {
- for {
- }
- }()
- time.Sleep(time.Millisecond)
- fmt.Println("腦子進煎魚了")
- }
這個例子在老版本的 Go 語言中，就會一直阻塞，沒法重見天日，是一個需要做搶占的場景。
但可能會有小伙伴問，搶占了，會不會有新問題。因為原本正在使用 P 的 M 就涼涼了(M 會與 P 進行綁定)，沒了 P 也就沒法繼續執行了。
這其實沒有問題，因為該 Goroutine 已經阻塞在了系統調用上，暫時是不會有后續的執行新訴求。
但萬一代碼是在運行了好一段時間后又能夠運行了(業務上也允許長等待)，也就是該 Goroutine 從阻塞狀態中恢復了，期望繼續運行，沒了 P 怎么辦?
這時候該 Goroutine 可以和其他 Goroutine 一樣，先檢查自身所在的 M 是否仍然綁定著 P：
- 若是有 P，則可以調整狀態，繼續運行。
- 若是沒有 P，可以重新搶 P，再占有并綁定 P，為自己所用。
也就是搶占 P，本身就是一個雙向行為，你搶了我的 P，我也可以去搶別人的 P 來繼續運行。
怎么搶占 P
講解了為什么要搶占 P 的原因后，我們進一步深挖，“他” 是怎么搶占到具體的 P 的呢?
這就涉及到前文所提到的 runtime.retake 方法了，其處理以下兩種場景：
搶占阻塞在系統調用上的 P。
搶占運行時間過長的 G。
在此主要針對搶占 P 的場景，分析如下：
- func retake(now int64) uint32 {
- n := 0
- // 防止發生變更，對所有 P 加鎖
- lock(&allpLock)
- // 走入主邏輯，對所有 P 開始循環處理
- for i := 0; i < len(allp); i++ {
- _p_ := allp[i]
- pd := &_p_.sysmontick
- s := _p_.status
- sysretake := false
- ...
- if s == _Psyscall {
- // 判斷是否超過 1 個 sysmon tick 周期
- t := int64(_p_.syscalltick)
- if !sysretake && int64(pd.syscalltick) != t {
- pd.syscalltick = uint32(t)
- pd.syscallwhen = now
- continue
- }
- ...
- }
- }
- unlock(&allpLock)
- return uint32(n)
- }
該方法會先對 allpLock 上鎖，這個變量含義如其名，allpLock 可以防止該數組發生變化。
其會保護 allp、idlepMask 和 timerpMask 屬性的無 P 讀取和大小變化，以及對 allp 的所有寫入操作，可以避免影響后續的操作。
場景一
前置處理完畢后，進入主邏輯，會使用萬能的 for 循環對所有的 P(allp)進行一個個處理。
- t := int64(_p_.syscalltick)
- if !sysretake && int64(pd.syscalltick) != t {
- pd.syscalltick = uint32(t)
- pd.syscallwhen = now
- continue
- }
第一個場景是：會對 syscalltick 進行判定，如果在系統調用(syscall)中存在超過 1 個 sysmon tick 周期(至少 20us)的任務，則會從系統調用中搶占 P，否則跳過。
場景二
如果未滿足會繼續往下，走到如下邏輯：
- func retake(now int64) uint32 {
- for i := 0; i < len(allp); i++ {
- ...
- if s == _Psyscall {
- // 從此處開始分析
- if runqempty(_p_) &&
- atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 &&
- pd.syscallwhen+10*1000*1000 > now {
- continue
- }
- ...
- }
- }
- unlock(&allpLock)
- return uint32(n)
- }
第二個場景，聚焦到這一長串的判斷中：
- runqempty(_p_) == true 方法會判斷任務隊列 P 是否為空，以此來檢測有沒有其他任務需要執行。
- atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 會判斷是否存在空閑 P 和正在進行調度竊取 G 的 P。
- pd.syscallwhen+10*1000*1000 > now 會判斷系統調用時間是否超過了 10ms。
這里奇怪的是 runqempty 方法明明已經判斷了沒有其他任務，這就代表了沒有任務需要執行，是不需要搶奪 P 的。
但實際情況是，由于可能會阻止 sysmon 線程的深度睡眠，最終還是希望繼續占有 P。
在完成上述判斷后，進入到搶奪 P 的階段：
- func retake(now int64) uint32 {
- for i := 0; i < len(allp); i++ {
- ...
- if s == _Psyscall {
- // 承接上半部分
- unlock(&allpLock)
- incidlelocked(-1)
- if atomic.Cas(&_p_.status, s, _Pidle) {
- if trace.enabled {
- traceGoSysBlock(_p_)
- traceProcStop(_p_)
- }
- n++
- _p_.syscalltick++
- handoffp(_p_)
- }
- incidlelocked(1)
- lock(&allpLock)
- }
- }
- unlock(&allpLock)
- return uint32(n)
- }
解鎖相關屬性：需要調用 unlock 方法解鎖 allpLock，從而實現獲取 sched.lock，以便繼續下一步。
減少閑置 M：需要在原子操作(CAS)之前減少閑置 M 的數量(假設有一個正在運行)。否則在發生搶奪 M 時可能會退出系統調用，遞增 nmidle 并報告死鎖事件。
修改 P 狀態：調用 atomic.Cas 方法將所搶奪的 P 狀態設為 idle，以便于交于其他 M 使用。
搶奪 P 和調控 M：調用 handoffp 方法從系統調用或鎖定的 M 中搶奪 P，會由新的 M 接管這個 P。
總結
至此完成了搶占 P 的基本流程，我們可得出滿足以下條件：
如果存在系統調用超時：存在超過 1 個 sysmon tick 周期(至少 20us)的任務，則會從系統調用中搶占 P。
如果沒有空閑的 P：所有的 P 都已經與 M 綁定。需要搶占當前正處于系統調用之，而實際上系統調用并不需要的這個 P 的情況，會將其分配給其它 M 去調度其它 G。
如果 P 的運行隊列里面有等待運行的 G，為了保證 P 的本地隊列中的 G 得到及時調度。而自己本身的 P 又忙于系統調用，無暇管理。此時會尋找另外一個 M 來接管 P，從而實現繼續調度 G 的目的。
參考
NUMA-aware scheduler for Go
go-under-the-hood
深入解析 Go-搶占式調度
Go語言調度器源代碼情景分析
