[[398986]]

本文轉(zhuǎn)載自微信公眾號「碼農(nóng)桃花源」，作者qcrao。轉(zhuǎn)載本文請聯(lián)系碼農(nóng)桃花源公眾號。

不知道大家在實(shí)際工作中有沒有遇到過老版本 Go 調(diào)度器的坑：死循環(huán)導(dǎo)致程序“死機(jī)”。我去年就遇到過，并且搞出了一起 P0 事故，還寫了篇弱智的找 bug 文章。

識別事故的本質(zhì)，并且用一個(gè)非常簡單的示例展示出來，是功力的一種體現(xiàn)。那次事故的原因可以簡化成如下的 demo：

demo-1

我來簡單解釋一下上面這個(gè)程序。在主 goroutine 里，先用 GoMAXPROCS 函數(shù)拿到 CPU 的邏輯核心數(shù) threads。這意味著 Go 進(jìn)程會創(chuàng)建 threads 個(gè)數(shù)的 P。接著，啟動(dòng)了 threads 個(gè)數(shù)的 goroutine，每個(gè) goroutine 都在執(zhí)行一個(gè)無限循環(huán)，并且這個(gè)無限循環(huán)只是簡單地執(zhí)行 x++。

接著，主 goroutine sleep 了 1 秒鐘;最后，打印 x 的值。

你可以自己思考一下，輸出會是什么?

如果你想出了答案，接著再看下面這個(gè) demo：

demo-2

我也來解釋一下，在主 goroutine 里，只啟動(dòng)了一個(gè) goroutine(雖然程序里用了一個(gè) for 循環(huán)，但其實(shí)只循環(huán)了一次，完全是為了和前面的 demo 看起來更協(xié)調(diào)一些)，同樣執(zhí)行了一個(gè) x++ 的無限 for 循環(huán)。

和前一個(gè) demo 的不同點(diǎn)在于，在主 goroutine 里，我們手動(dòng)執(zhí)行了一次 GC;最后，打印 x 的值。

如果你能答對第一題，大概率也能答對第二題。

下面我就來揭曉答案。

其實(shí)我留了一個(gè)坑，我沒說用哪個(gè)版本的 Go 來運(yùn)行代碼。所以，正確的答案是：

這個(gè)其實(shí)就是 Go 調(diào)度器的坑了。

假設(shè)在 demo-1 中，共有 4 個(gè) P，于是創(chuàng)建了 4 個(gè) goroutine。當(dāng)主 goroutine 執(zhí)行 sleep 的時(shí)候，剛剛創(chuàng)建的 4 個(gè) goroutine 馬上就把 4 個(gè) P 霸占了，執(zhí)行死循環(huán)，而且竟然沒有進(jìn)行函數(shù)調(diào)用，就只有一個(gè)簡單的賦值語句。Go 1.13 對這種情況是無能為力的，沒有任何辦法讓這些 goroutine 停下來，進(jìn)程對外表現(xiàn)出“死機(jī)”。

demo-1 示意圖

由于 Go 1.14 實(shí)現(xiàn)了基于信號的搶占式調(diào)度，這些執(zhí)行無限循環(huán)的 goroutine 會被調(diào)度器“拿下”，P 就會空出來。所以當(dāng)主 goroutine sleep 時(shí)間到了之后，馬上就能獲得 P，并得以打印出 x 的值。至于 x 為什么輸出的是 0，不太好解釋，因?yàn)檫@是一種未定義(有數(shù)據(jù)競爭，正常情況下要加鎖)的行為，可能的一個(gè)原因是 CPU 的 cache 沒有來得及更新，不過不太好驗(yàn)證。

理解了這個(gè) demo，第二個(gè) demo 其實(shí)是類似的道理：

demo-2 示意圖

當(dāng)主 goroutine 主動(dòng)觸發(fā) GC 時(shí)，需要把所有當(dāng)前正在運(yùn)行的 goroutine 停止下來，即 stw(stop the world)，但是 goroutine 正在執(zhí)行無限循環(huán)，沒法讓它停下來。當(dāng)然，Go 1.14 還是可以搶占掉這個(gè) goroutine，從而打印出 x 的值，也是 0。

Go 1.14 之前的版本，能否搶占一個(gè)正在執(zhí)行死循環(huán)的 goroutine 其實(shí)是有講究的：

能否被搶占，不是看有沒有調(diào)用函數(shù)，而是看函數(shù)的序言部分有沒有插入擴(kuò)棧檢測指令。

如果沒有調(diào)用函數(shù)，肯定不會被搶占。

有些雖然也調(diào)用了函數(shù)，但其實(shí)不會插入檢測指令，這個(gè)時(shí)候也不會被搶占。

像前面的兩個(gè) demo，不可能有機(jī)會在函數(shù)擴(kuò)棧檢測期間主動(dòng)放棄 CPU 使用權(quán)，從而完成搶占，因?yàn)闆]有函數(shù)調(diào)用。具體的過程后面有機(jī)會再寫一篇文章詳細(xì)講，本文主要看基于信號的搶占式調(diào)度如何實(shí)現(xiàn)。

preemptone

一方面，Go 進(jìn)程在啟動(dòng)的時(shí)候，會開啟一個(gè)后臺線程 sysmon，監(jiān)控執(zhí)行時(shí)間過長的 goroutine，進(jìn)而發(fā)出搶占。另一方面，GC 執(zhí)行 stw 時(shí)，會讓所有的 goroutine 都停止，其實(shí)就是搶占。這兩者都會調(diào)用 preemptone() 函數(shù)。

preemptone() 函數(shù)會沿著下面這條路徑：

preemptone->preemptM->signalM->tgkill 

向正在運(yùn)行的 goroutine 所綁定的的那個(gè) M(也可以說是線程)發(fā)出 SIGURG 信號。

注冊 sighandler

每個(gè) M 在初始化的時(shí)候都會設(shè)置信號處理函數(shù)：

initsig->setsig->sighandler 

信號執(zhí)行過程

我們從“宏觀”層面看一下信號的執(zhí)行過程：

信號執(zhí)行過程

主程序(線程)正在“勤勤懇懇”地執(zhí)行指令：它已經(jīng)執(zhí)行完了指令 m，接著就要執(zhí)行指令 m+1 了……不幸在這個(gè)時(shí)候發(fā)生了，線程收到了一個(gè)信號，對應(yīng)圖中的 ①。

接著，內(nèi)核會接管執(zhí)行流，轉(zhuǎn)而去執(zhí)行預(yù)先設(shè)置好的信號處理器程序，對應(yīng)到 Go 里，就是執(zhí)行 sighandler，對應(yīng)圖中的 ② 和 ③。

最后，執(zhí)行流又交到線程手上，繼續(xù)執(zhí)行指令 m+1，對應(yīng)圖中的 ④。

這里其實(shí)涉及到了一些現(xiàn)場的保護(hù)和恢復(fù)，內(nèi)核都幫我們搞定了，我們不用操心。

dosigPreempt

當(dāng)線程收到 SIGURG 信號的時(shí)候，就會去執(zhí)行 sighandler 函數(shù)，核心是 doSigPreempt 函數(shù)。

func sighandler(sig uint32, info *siginfo, ctxt unsafe.Pointer, gp *g) { 
    ... 
     
    if sig == sigPreempt && debug.asyncpreemptoff == 0 { 
  doSigPreempt(gp, c) 
 } 
  
 ... 
} 

doSigPreempt 這個(gè)函數(shù)其實(shí)很短，一會兒就執(zhí)行完了。

func doSigPreempt(gp *g, ctxt *sigctxt) { 
 ... 
 if ok, newpc := isAsyncSafePoint(gp, ctxt.sigpc(), ctxt.sigsp(), ctxt.siglr()); ok { 
  // Adjust the PC and inject a call to asyncPreempt. 
  ctxt.pushCall(funcPC(asyncPreempt), newpc) 
 } 
 ... 
} 

isAsyncSafePoint 函數(shù)會返回當(dāng)前 goroutine 能否被搶占，以及從哪條指令開始搶占，返回的 newpc 表示安全的搶占地址。

接著，pushCall 調(diào)整了一下 SP，設(shè)置了幾個(gè)寄存器的值就返回了。按理說，返回之后，就會接著執(zhí)行指令 m+1 了，但那還怎么實(shí)現(xiàn)搶占呢?其實(shí)魔法都在 pushCall 這個(gè)函數(shù)里。

pushCall

在分析這個(gè)函數(shù)之前，我們需要先復(fù)習(xí)一下 Go 函數(shù)的調(diào)用規(guī)約，重點(diǎn)回顧一下 CALL 和 RET 指令就行了。

call 和 ret 指令

call 指令可以簡單地理解為 push ip + JMP。這個(gè) ip 其實(shí)就是返回地址，也就是調(diào)用完子函數(shù)接下來該執(zhí)行啥指令的地址。所以 push ip 就是在 call 一個(gè)子函數(shù)之前，將返回地址壓入棧中，然后 JMP 到子函數(shù)的地址執(zhí)行。

ret 指令和 call 指令剛好相反，它將返回地址從棧上 pop 到 IP 寄存器，使得 CPU 從這個(gè)地址繼續(xù)執(zhí)行。

理解了 call 和 ret，我們再來分析 pushCall 函數(shù)：

func (c *sigctxt) pushCall(targetPC, resumePC uintptr) { 
 // Make it look like we called target at resumePC. 
 sp := uintptr(c.rsp()) 
 sp -= sys.PtrSize 
 *(*uintptr)(unsafe.Pointer(sp)) = resumePC 
 c.set_rsp(uint64(sp)) 
 c.set_rip(uint64(targetPC)) 
} 

注意看這行注釋：

// Make it look like we called target at resumePC. 

它清晰地說明了這個(gè)函數(shù)的作用：讓 CPU 誤以為是 resumePC 調(diào)用了 targetPC。而這個(gè) resumePC 就是上一步調(diào)用 isAsyncSafePoint 函數(shù)返回的 newpc，它代表我們搶占 goroutine 的指令地址。

前兩行代碼將 SP 下移了 8 個(gè)字節(jié)，并且把 resumePC 入棧(注意，它其實(shí)是一個(gè)返回地址)，接著把 targetPC 設(shè)置到 ip 寄存器，sp 設(shè)置到 SP 寄存器。這使得從內(nèi)核返回到用戶態(tài)執(zhí)行時(shí)，不是從指令 m+1，而是直接從 targetPC 開始執(zhí)行，等到 targetPC 執(zhí)行完，才會返回到 resumePC 繼續(xù)執(zhí)行。整個(gè)過程就像是 resumePC 調(diào)用了 targetPC 一樣。而 targetPC 其實(shí)就是 funcPC(asyncPreempt)，也就是搶占函數(shù)。

于是我們可以看到，信號處理器程序 sighandler 只是將一個(gè)異步搶占函數(shù)給“安插”進(jìn)來了，而真正的搶占過程則是在 asyncPreempt 函數(shù)中完成。

異步搶占

當(dāng)執(zhí)行完 sighandler，執(zhí)行流再次回到線程。由于 sighandler 插入了一個(gè) asyncPreempt 的函數(shù)調(diào)用，所以 goroutine 原本的任務(wù)就得不到推進(jìn)，轉(zhuǎn)而執(zhí)行 asyncPreempt 去了：

asyncPreempt 調(diào)用鏈路

mcall(fn) 的作用是切到 g0 棧去執(zhí)行函數(shù) fn, fn 永不返回。在 mcall(gopreempt_m) 這里，fn 就是 gopreempt_m。

gopreempt_m 直接調(diào)用 goschedImpl：

goschedImpl

dropg

最精彩的部分就在 goschedImpl 函數(shù)。它首先將 goroutine 的狀態(tài)從 running 改成 runnable;接著調(diào) dropg 將 g 和 m 解綁;然后調(diào)用 globrunqput 將 goroutine 丟到全局可運(yùn)行隊(duì)列，由于是全局可運(yùn)行隊(duì)列，所以需要加鎖。最后，調(diào)用 schedule() 函數(shù)進(jìn)入調(diào)度循環(huán)。關(guān)于調(diào)度循環(huán)，可以看這篇文章。

運(yùn)行 schedule 函數(shù)用的是 g0 棧，它會去尋找其他可運(yùn)行的 goroutine，包括從當(dāng)前 P 本地可運(yùn)行隊(duì)列獲取、從全局可運(yùn)行隊(duì)列獲取、從其他 P 偷等方式找到下一個(gè)可運(yùn)行的 goroutine 并執(zhí)行。

至此，這個(gè)線程就轉(zhuǎn)而去執(zhí)行其他的 goroutine，當(dāng)前的 goroutine 也就被搶占了。

那被搶占的這個(gè) goroutine 什么時(shí)候會再次得到執(zhí)行呢?

因?yàn)樗呀?jīng)被丟到全局可運(yùn)行隊(duì)列了，所以它的優(yōu)先級就會降低，得到調(diào)度的機(jī)會也就降低，但總還是有機(jī)會再次執(zhí)行的，并且它會從調(diào)用 mcall 的下一條指令接著執(zhí)行。

還記得 mcall 函數(shù)的作用嗎?它會切到 g0 棧執(zhí)行 gopreempt_m，自然它也會保存 goroutine 的執(zhí)行進(jìn)度，其實(shí)就是 SP、BP、PC 寄存器的值，當(dāng) goroutine 再次被調(diào)度執(zhí)行時(shí)，就會從原來的執(zhí)行流斷點(diǎn)處繼續(xù)執(zhí)行下去。

總結(jié)

本文講述了 Go 語言基于信號的異步搶占的全過程，一起來回顧下：

M 注冊一個(gè) SIGURG 信號的處理函數(shù)：sighandler。

sysmon 線程檢測到執(zhí)行時(shí)間過長的 goroutine、GC stw 時(shí)，會向相應(yīng)的 M(或者說線程，每個(gè)線程對應(yīng)一個(gè) M)發(fā)送 SIGURG 信號。

收到信號后，內(nèi)核執(zhí)行 sighandler 函數(shù)，通過 pushCall 插入 asyncPreempt 函數(shù)調(diào)用。

回到當(dāng)前 goroutine 執(zhí)行 asyncPreempt 函數(shù)，通過 mcall 切到 g0 棧執(zhí)行 gopreempt_m。

將當(dāng)前 goroutine 插入到全局可運(yùn)行隊(duì)列，M 則繼續(xù)尋找其他 goroutine 來運(yùn)行。

被搶占的 goroutine 再次調(diào)度過來執(zhí)行時(shí)，會繼續(xù)原來的執(zhí)行流。