[[393948]]

本文轉(zhuǎn)載自微信公眾號「腦子進(jìn)煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號。

大家好，我是煎魚。

昨天剛從長沙浪完回來，準(zhǔn)備 ”瀟瀟灑灑“ 寫一篇游記，分享一波美食+游記，有五一準(zhǔn)備去長沙玩的小伙伴嗎?

前幾天我們有聊到《單核 CPU，開兩個 Goroutine，其中一個死循環(huán)，會怎么樣?》的問題，我們在一個細(xì)節(jié)部分有提到：

有新的小伙伴會產(chǎn)生更多的疑問，那就是在 Go 語言中，是如何搶占 P 的呢，這里面是怎么做的?

今天這篇文章我們就來解密搶占 P。

調(diào)度器的發(fā)展史

在 Go 語言中，Goroutine 早期是沒有設(shè)計(jì)成搶占式的，早期 Goroutine 只有讀寫、主動讓出、鎖等操作時才會觸發(fā)調(diào)度切換。

這樣有一個嚴(yán)重的問題，就是垃圾回收器進(jìn)行 STW 時，如果有一個 Goroutine 一直都在阻塞調(diào)用，垃圾回收器就會一直等待他，不知道等到什么時候...

這種情況下就需要搶占式調(diào)度來解決問題。如果一個 Goroutine 運(yùn)行時間過久，就需要進(jìn)行搶占來解決。

這塊 Go 語言在 Go1.2 起開始實(shí)現(xiàn)搶占式調(diào)度器，不斷完善直至今日：

• Go0.x：基于單線程的程調(diào)度器。
• Go1.0：基于多線程的調(diào)度器。
• Go1.1：基于任務(wù)竊取的調(diào)度器。
• Go1.2 - Go1.13：基于協(xié)作的搶占式調(diào)度器。
• Go1.14：基于信號的搶占式調(diào)度器。

調(diào)度器的新提案：非均勻存儲器訪問調(diào)度(Non-uniform memory access，NUMA)， 但由于實(shí)現(xiàn)過于復(fù)雜，優(yōu)先級也不夠高，因此遲遲未提上日程。

有興趣的小伙伴可以詳見 Dmitry Vyukov, dvyukov 所提出的 NUMA-aware scheduler for Go。

為什么要搶占 P

為什么會要想去搶占 P 呢，說白了就是不搶，就沒機(jī)會運(yùn)行，會 hang 死。又或是資源分配不均了，

這在調(diào)度器設(shè)計(jì)中顯然是不合理的。

跟這個例子一樣：

// Main Goroutine  
func main() { 
    // 模擬單核 CPU 
    runtime.GOMAXPROCS(1) 
     
    // 模擬 Goroutine 死循環(huán) 
    go func() { 
        for { 
        } 
    }() 
 
    time.Sleep(time.Millisecond) 
    fmt.Println("腦子進(jìn)煎魚了") 
} 

這個例子在老版本的 Go 語言中，就會一直阻塞，沒法重見天日，是一個需要做搶占的場景。

但可能會有小伙伴問，搶占了，會不會有新問題。因?yàn)樵菊谑褂?P 的 M 就涼涼了(M 會與 P 進(jìn)行綁定)，沒了 P 也就沒法繼續(xù)執(zhí)行了。

這其實(shí)沒有問題，因?yàn)樵?Goroutine 已經(jīng)阻塞在了系統(tǒng)調(diào)用上，暫時是不會有后續(xù)的執(zhí)行新訴求。

但萬一代碼是在運(yùn)行了好一段時間后又能夠運(yùn)行了(業(yè)務(wù)上也允許長等待)，也就是該 Goroutine 從阻塞狀態(tài)中恢復(fù)了，期望繼續(xù)運(yùn)行，沒了 P 怎么辦?

這時候該 Goroutine 可以和其他 Goroutine 一樣，先檢查自身所在的 M 是否仍然綁定著 P：

1. 若是有 P，則可以調(diào)整狀態(tài)，繼續(xù)運(yùn)行。
2. 若是沒有 P，可以重新?lián)?P，再占有并綁定 P，為自己所用。

也就是搶占 P，本身就是一個雙向行為，你搶了我的 P，我也可以去搶別人的 P 來繼續(xù)運(yùn)行。

怎么搶占 P

講解了為什么要搶占 P 的原因后，我們進(jìn)一步深挖，“他” 是怎么搶占到具體的 P 的呢?

這就涉及到前文所提到的 runtime.retake 方法了，其處理以下兩種場景：

搶占阻塞在系統(tǒng)調(diào)用上的 P。

搶占運(yùn)行時間過長的 G。

在此主要針對搶占 P 的場景，分析如下：

func retake(now int64) uint32 { 
 n := 0 
 // 防止發(fā)生變更，對所有 P 加鎖 
 lock(&allpLock) 
 // 走入主邏輯，對所有 P 開始循環(huán)處理 
 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 可以防止該數(shù)組發(fā)生變化。

其會保護(hù) allp、idlepMask 和 timerpMask 屬性的無 P 讀取和大小變化，以及對 allp 的所有寫入操作，可以避免影響后續(xù)的操作。

場景一

前置處理完畢后，進(jìn)入主邏輯，會使用萬能的 for 循環(huán)對所有的 P(allp)進(jìn)行一個個處理。

t := int64(_p_.syscalltick) 
if !sysretake && int64(pd.syscalltick) != t { 
 pd.syscalltick = uint32(t) 
 pd.syscallwhen = now 
 continue 
} 

第一個場景是：會對 syscalltick 進(jìn)行判定，如果在系統(tǒng)調(diào)用(syscall)中存在超過 1 個 sysmon tick 周期(至少 20us)的任務(wù)，則會從系統(tǒng)調(diào)用中搶占 P，否則跳過。

場景二

如果未滿足會繼續(xù)往下，走到如下邏輯：

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 方法會判斷任務(wù)隊(duì)列 P 是否為空，以此來檢測有沒有其他任務(wù)需要執(zhí)行。
• atomic.Load(&sched.nmspinning)+atomic.Load(&sched.npidle) > 0 會判斷是否存在空閑 P 和正在進(jìn)行調(diào)度竊取 G 的 P。
• pd.syscallwhen+10*1000*1000 > now 會判斷系統(tǒng)調(diào)用時間是否超過了 10ms。

這里奇怪的是 runqempty 方法明明已經(jīng)判斷了沒有其他任務(wù)，這就代表了沒有任務(wù)需要執(zhí)行，是不需要搶奪 P 的。

但實(shí)際情況是，由于可能會阻止 sysmon 線程的深度睡眠，最終還是希望繼續(xù)占有 P。

在完成上述判斷后，進(jìn)入到搶奪 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) 
} 

解鎖相關(guān)屬性：需要調(diào)用 unlock 方法解鎖 allpLock，從而實(shí)現(xiàn)獲取 sched.lock，以便繼續(xù)下一步。

減少閑置 M：需要在原子操作(CAS)之前減少閑置 M 的數(shù)量(假設(shè)有一個正在運(yùn)行)。否則在發(fā)生搶奪 M 時可能會退出系統(tǒng)調(diào)用，遞增 nmidle 并報(bào)告死鎖事件。

修改 P 狀態(tài)：調(diào)用 atomic.Cas 方法將所搶奪的 P 狀態(tài)設(shè)為 idle，以便于交于其他 M 使用。

搶奪 P 和調(diào)控 M：調(diào)用 handoffp 方法從系統(tǒng)調(diào)用或鎖定的 M 中搶奪 P，會由新的 M 接管這個 P。

總結(jié)

至此完成了搶占 P 的基本流程，我們可得出滿足以下條件：

如果存在系統(tǒng)調(diào)用超時：存在超過 1 個 sysmon tick 周期(至少 20us)的任務(wù)，則會從系統(tǒng)調(diào)用中搶占 P。

如果沒有空閑的 P：所有的 P 都已經(jīng)與 M 綁定。需要搶占當(dāng)前正處于系統(tǒng)調(diào)用之，而實(shí)際上系統(tǒng)調(diào)用并不需要的這個 P 的情況，會將其分配給其它 M 去調(diào)度其它 G。

如果 P 的運(yùn)行隊(duì)列里面有等待運(yùn)行的 G，為了保證 P 的本地隊(duì)列中的 G 得到及時調(diào)度。而自己本身的 P 又忙于系統(tǒng)調(diào)用，無暇管理。此時會尋找另外一個 M 來接管 P，從而實(shí)現(xiàn)繼續(xù)調(diào)度 G 的目的。

參考

NUMA-aware scheduler for Go

go-under-the-hood

深入解析 Go-搶占式調(diào)度

Go語言調(diào)度器源代碼情景分析