前言

Goroutine & Scheduler

goroutine 是什么？通常 goroutine 會被當做 coroutine（協程）的 golang 實現，但實際上，goroutine 并非傳統意義上的協程，現在主流的線程模型分三種：內核級線程模型、用戶級線程模型和兩級線程模型（也稱混合型線程模型），傳統的協程庫屬于用戶級線程模型，而 goroutine 和它的 Go Scheduler 在底層實現上其實是屬于兩級線程模型。

線程模型

內核級線程模型

用戶線程與內核線程 KSE 是一對一（1 : 1）的映射模型，也就是每一個用戶線程綁定一個實際的內核線程，而線程的調度則完全交付給操作系統內核去做，應用程序對線程的創建、終止以及同步都基于內核提供的系統調用來完成，大部分編程語言的線程庫(比如 Java 的 java.lang.Thread、C++11 的 std::thread 等等)都是對操作系統的線程（內核級線程）的一層封裝，創建出來的每個線程與一個獨立的 KSE 靜態綁定，因此其調度完全由操作系統內核調度器去做，也就是說，一個進程里創建出來的多個線程每一個都綁定一個 KSE。

用戶級線程模型

用戶線程與內核線程 KSE 是多對一（N : 1）的映射模型，多個用戶線程的一般從屬于單個進程并且多線程的調度是由用戶自己的線程庫來完成，線程的創建、銷毀以及多線程之間的協調等操作都是由用戶自己的線程庫來負責而無須借助系統調用來實現。一個進程中所有創建的線程都只和同一個 KSE 在運行時動態綁定，也就是說，操作系統只知道用戶進程而對其中的線程是無感知的，內核的所有調度都是基于用戶進程。這種實現方式相比內核級線程可以做的很輕量級，對系統資源的消耗會小很多，因此可以創建的線程數量與上下文切換所花費的代價也會小得多。但該模型有個原罪：并不能做到真正意義上的并發，假設在某個用戶進程上的某個用戶線程因為一個阻塞調用（比如 I/O 阻塞）而被 CPU 給中斷（搶占式調度）了，那么該進程內的所有線程都被阻塞（因為單個用戶進程內的線程自調度是沒有 CPU 時鐘中斷的，從而沒有輪轉調度），整個進程被掛起。即便是多 CPU 的機器，也無濟于事，因為在用戶級線程模型下，一個 CPU 關聯運行的是整個用戶進程，進程內的子線程綁定到 CPU 執行是由用戶進程調度的，內部線程對 CPU 是不可見的，此時可以理解為 CPU 的調度單位是用戶進程。所以很多的協程庫會把自己一些阻塞的操作重新封裝為完全的非阻塞形式，然后在以前要阻塞的點上，主動讓出自己，并通過某種方式通知或喚醒其他待執行的用戶線程在該 KSE 上運行，從而避免了內核調度器由于 KSE 阻塞而做上下文切換，這樣整個進程也不會被阻塞了。

兩級線程模型

用戶線程與內核 KSE 是多對多（N : M）的映射模型：首先，區別于用戶級線程模型，兩級線程模型中的一個進程可以與多個內核線程 KSE 關聯，也就是說一個進程內的多個線程可以分別綁定一個自己的 KSE，這點和內核級線程模型相似；其次，又區別于內核級線程模型，它的進程里的線程并不與 KSE 唯一綁定，而是可以多個用戶線程映射到同一個 KSE，當某個 KSE 因為其綁定的線程的阻塞操作被內核調度出 CPU 時，其關聯的進程中其余用戶線程可以重新與其他 KSE 綁定運行。即用戶調度器實現用戶線程到 KSE 的『調度』，內核調度器實現 KSE 到 CPU 上的『調度』。

G-P-M 模型概述

在 Go 語言中，每一個 goroutine 是一個獨立的執行單元，相較于每個 OS 線程固定分配 2M 內存的模式，goroutine 的棧采取了動態擴容方式， 初始時僅為2KB，隨著任務執行按需增長，最大可達 1GB（64 位機器最大是 1G，32 位機器最大是 256M），且完全由 golang 自己的調度器 Go Scheduler 來調度。此外，GC 還會周期性地將不再使用的內存回收，收縮棧空間。 因此，Go 程序可以同時并發成千上萬個 goroutine 是得益于它強勁的調度器和高效的內存模型。

調度算法

GPM

• G: 表示 Goroutine，每個 Goroutine 對應一個 G 結構體，G 存儲 Goroutine 的運行堆棧、狀態以及任務函數，可重用。G 并非執行體，每個 G 需要綁定到 P 才能被調度執行。

• P: Processor，表示邏輯處理器， 對 G 來說，P 相當于 CPU 核，G 只有綁定到 P(在 P 的 local runq 中)才能被調度。對 M 來說，P 提供了相關的執行環境(Context)，如內存分配狀態(mcache)，任務隊列(G)等，P 的數量決定了系統內最大可并行的 G 的數量（前提：物理 CPU 核數 >= P 的數量），P 的數量由用戶設置的 GOMAXPROCS 決定，但是不論 GOMAXPROCS 設置為多大，P 的數量最大為 256。

• M: Machine，OS 線程抽象，代表著真正執行計算的資源，在綁定有效的 P 后，進入 schedule 循環；而 schedule 循環的機制大致是從 Global 隊列、P 的 Local 隊列以及 wait 隊列中獲取 G，切換到 G 的執行棧上并執行 G 的函數，調用 goexit 做清理工作并回到 M，如此反復。M 并不保留 G 狀態，這是 G 可以跨 M 調度的基礎，M 的數量是不定的，由 Go Runtime 調整，為了防止創建過多 OS 線程導致系統調度不過來，目前默認最大限制為 10000 個。

• 每個 P 維護一個 G 的本地隊列；

• 當一個 G 被創建出來，或者變為可執行狀態時，就把他放到 P 的本地可執行隊列中，如果滿了則放入Global；

• 當一個 G 在 M 里執行結束后，P 會從隊列中把該 G 取出；如果此時 P 的隊列為空，即沒有其他 G 可以執行， M 就隨機選擇另外一個 P，從其可執行的 G 隊列中取走一半。

調度過程

當通過 go 關鍵字創建一個新的 goroutine 的時候，它會優先被放入 P 的本地隊列。為了運行 goroutine，M 需要持有（綁定）一個 P，接著 M 會啟動一個 OS 線程，循環從 P 的本地隊列里取出一個 goroutine 并執行。執行調度算法：當 M 執行完了當前 P 的 Local 隊列里的所有 G 后，P 也不會就這么在那劃水啥都不干，它會先嘗試從 Global 隊列尋找 G 來執行，如果 Global 隊列為空，它會隨機挑選另外一個 P，從它的隊列里中拿走一半的 G 到自己的隊列中執行。

阻塞

Go runtime 會在下面的 goroutine 被阻塞的情況下運行另外一個 goroutine：

• blocking syscall (for example opening a file)
• network input
• channel operations
• primitives in the sync package

這四種場景又可歸類為兩種類型：

用戶態阻塞/喚醒

當 goroutine 因為 channel 操作阻塞時，對應的 G 會被放置到某個 wait 隊列(如 channel 的 waitq)，該 G 的狀態由_Gruning 變為 _Gwaitting ，而 M 會跳過該 G 嘗試獲取并執行下一個 G，如果此時沒有 runnable 的 G 供 M 運行，那么 M 將解綁 P，并進入 sleep 狀態；當阻塞的 G 被另一端的 G2 喚醒時（比如 channel 的可讀/寫通知），G 被標記為 runnable，嘗試加入 G2 所在 P 的 runnext，然后再是 P 的 Local 隊列和 Global 隊列。

系統調用阻塞

當 G 被阻塞在某個系統調用上時，此時 G 會阻塞在 _Gsyscall 狀態，M 也處于 block on syscall 狀態，此時的 M 可被搶占調度：執行該 G 的 M 會與 P 解綁，而 P 則嘗試與其它空閑的 M 綁定，繼續執行其它 G。如果沒有其它空閑的 M，但 P 的 Local 隊列中仍然有 G 需要執行，則創建一個新的 M；當系統調用完成后，G 會重新嘗試獲取一個空閑的 P 進入它的 Local 隊列恢復執行，如果沒有空閑的 P，G 會被標記為 runnable 加入到 Global 隊列。

參考&致謝

• Go 并發編程實戰（第 2 版）
• Go 語言學習筆記
• go-coding-in-go-way
• Goroutine 并發調度模型深度解析
• 也談 goroutine 調度器
• The Go scheduler