深度解密Go语言之scheduler
好久不見，你還好嗎？距離上一篇文章已經過去了一個多月了，遲遲未更新文章，我也很著急啊，哈哈。
跟大家匯報一下，這段時間我在看 proc.go 的源碼，其實就是調度器的源碼。代碼有幾千行之多，不像以往的 map，channel 等等。想把這些代碼都看明白，是一個龐大的工程。到今天為止，我也不敢說我都看明白了。
要深挖下去的話，會無窮無盡，所以階段性的探索就到這里。接下來就把這段時間的探索分享出來。
其實，今天這篇文章僅僅算是一個引子，接下來會連續發布十篇系列文章。目錄如下：
而這個系列的文章主要是受公眾號“go 語言核心編程技術”的啟發，它有一個 Go 調度器的系列教程，寫得非常贊，強烈推薦大家去看，后面會經常引用到它的文章。我忍不住在這貼上公眾號的二維碼，一定要去關注啊。這是我在找資料的過程中發現的一個寶藏，本來想私藏著，但是好東西還是要分享給大家，不能固步自封。
開始我們今天的正題。
一個月前，《Go 語言高級編程》作者柴樹杉老師在 CSDN 上發表了一篇《Go 語言十年而立，Go2 蓄勢待發》，視角十分宏大。我們既要低頭看路，有時也要抬頭看天，這篇文章就屬于“抬頭”看天類的，推薦閱讀。
文章中提到了第一本寫 Go 的小說《胡文 Go》。我找來看了下，嬉笑怒罵，還挺有意思的。書中有這樣一句話：
在 Go 語言里，go func 是并發的單元，chan 是協調并發單元的機制，panic 和 recover 是出錯處理的機制，而 defer 是神來之筆，大大簡化了出錯的管理。
Goroutines 在同一個用戶空間里同時獨立執行 functions，channels 則用于 goroutines 間的通信和同步訪問控制。
上一篇文章里我們講了 channel，并且提到，goroutine 和 channel 是 Go 并發編程的兩大基石，那這篇文章就聚焦到 goroutine，以及調度 goroutine 的 go scheduler。
按照慣例，手動貼上本文的目錄：
前置知識
os scheduler
從操作系統角度看，我們寫的程序最終都會轉換成一系列的機器指令，機器只要按順序執行完所有的指令就算完成了任務。完成“按順序執行指令”任務的實體就是線程，也就是說，線程是 CPU 調度的實體，線程是真正在 CPU 上執行指令的實體。
每個程序啟動的時候，都會創建一個初始進程，并且啟動一個線程。而線程可以去創建更多的線程，這些線程可以獨立地執行，CPU 在這一層進行調度，而非進程。
OS scheduler 保證如果有可以執行的線程時，就不會讓 CPU 閑著。并且它還要保證，所有可執行的線程都看起來在同時執行。另外，OS scheduler 在保證高優先級的線程執行機會大于低優先級線程的同時，不能讓低優先級的線程始終得不到執行的機會。OS scheduler 還需要做到迅速決策，以降低延時。
線程切換
OS scheduler 調度線程的依據就是它的狀態，線程有三種狀態（簡化模型）：Waiting, Runnable or Executing。
| Waiting | 等待狀態。線程在等待某件事的發生。例如等待網絡數據、硬盤；調用操作系統 API；等待內存同步訪問條件 ready，如 atomic, mutexes |
| Runnable | 就緒狀態。只要給 CPU 資源我就能運行 |
| Executing | 運行狀態。線程在執行指令，這是我們想要的 |
線程能做的事一般分為兩種：計算型、IO 型。
計算型主要是占用 CPU 資源，一直在做計算任務，例如對一個大數做質數分解。這種類型的任務不會讓線程跳到 Waiting 狀態。
IO 型則是要獲取外界資源，例如通過網絡、系統調用等方式。內存同步訪問控制原語：mutexes 也可以看作這種類型。共同特點是需要等待外界資源就緒。IO 型的任務會讓線程跳到 Waiting 狀態。
線程切換就是操作系統用一個處于 Runnable 的線程將 CPU 上正在運行的處于 Executing 狀態的線程換下來的過程。新上場的線程會變成 Executing 狀態，而下場的線程則可能變成 Waiting 或 Runnable 狀態。正在做計算型任務的線程，會變成 Runnable 狀態；正在做 IO 型任務的線程，則會變成 Waiting 狀態。
因此，計算密集型任務和 IO 密集型任務對線程切換的“態度”是不一樣的。由于計算型密集型任務一直都有任務要做，或者說它一直有指令要執行，線程切換的過程會讓它停掉當前的任務，損失非常大。
相反，專注于 IO 密集型的任務的線程，如果它因為某個操作而跳到 Waiting 狀態，那么把它從 CPU 上換下，對它而言是沒有影響的。而且，新換上來的線程可以繼續利用 CPU 完成任務。從整個操作系統來看，“工作進度”是往前的。
記住，對于 OS scheduler 來說，最重要的是不要讓一個 CPU 核心閑著，盡量讓每個 CPU 核心都有任務可做。
If you have a program that is focused on IO-Bound work, then context switches are going to be an advantage. Once a Thread moves into a Waiting state, another Thread in a Runnable state is there to take its place. This allows the core to always be doing work. This is one of the most important aspects of scheduling. Don’t allow a core to go idle if there is work (Threads in a Runnable state) to be done.
函數調用過程分析
要想理解 Go scheduler 的底層原理，對于函數調用過程的理解是必不可少的。它涉及到函數參數的傳遞，CPU 的指令跳轉，函數返回值的傳遞等等。這需要對匯編語言有一定的了解，因為只有匯編語言才能進行像寄存器賦值這樣的底層操作。之前的一些文章里也有說明，這里再來復習一遍。
函數棧幀的空間主要由函數參數和返回值、局部變量和被調用其它函數的參數和返回值空間組成。
宏觀看一下，Go 語言中函數調用的規范，引用曹大博客里的一張圖：
Go plan9 匯編通過棧傳遞函數參數和返回值。
調用子函數時，先將參數在棧頂準備好，再執行 CALL 指令。CALL 指令會將 IP 寄存器的值壓棧，這個值就是函數調用完成后即將執行的下一條指令。
然后，就會進入被調用者的棧幀。首先會將 caller BP 壓棧，這表示棧基址，也就是棧底。棧頂和?；范x函數的棧幀。
CALL 指令類似 PUSH IP 和 JMP somefunc 兩個指令的組合，首先將當前的 IP 指令寄存器的值壓入棧中，然后通過 JMP 指令將要調用函數的地址寫入到 IP 寄存器實現跳轉。
而 RET 指令則是和 CALL 相反的操作，基本和 POP IP 指令等價，也就是將執行 CALL 指令時保存在 SP 中的返回地址重新載入到 IP 寄存器，實現函數的返回。
首先是調用函數前準備的輸入參數和返回值空間。然后 CALL 指令將首先觸發返回地址入棧操作。在進入到被調用函數內之后，匯編器自動插入了 BP 寄存器相關的指令，因此 BP 寄存器和返回地址是緊挨著的。再下面就是當前函數的局部變量的空間，包含再次調用其它函數需要準備的調用參數空間。被調用的函數執行 RET 返回指令時，先從?；謴?BP 和 SP 寄存器，接著取出的返回地址跳轉到對應的指令執行。
上面兩段描述來自《Go 語言高級編程》一書的匯編語言章節，說得很好，再次推薦閱讀。
goroutine 是怎么工作的
什么是 goroutine
Goroutine 可以看作對 thread 加的一層抽象，它更輕量級，可以單獨執行。因為有了這層抽象，Gopher 不會直接面對 thread，我們只會看到代碼里滿天飛的 goroutine。操作系統卻相反，管你什么 goroutine，我才沒空理會。我安心地執行線程就可以了，線程才是我調度的基本單位。
goroutine 和 thread 的區別
談到 goroutine，繞不開的一個話題是：它和 thread 有什么區別？
參考資料【How Goroutines Work】告訴我們可以從三個角度區別：內存消耗、創建與銷毀、切換。
內存占用
創建一個 goroutine 的棧內存消耗為 2 KB，實際運行過程中，如果?？臻g不夠用，會自動進行擴容。創建一個 thread 則需要消耗 1 MB 棧內存，而且還需要一個被稱為 “a guard page” 的區域用于和其他 thread 的棧空間進行隔離。
對于一個用 Go 構建的 HTTP Server 而言，對到來的每個請求，創建一個 goroutine 用來處理是非常輕松的一件事。而如果用一個使用線程作為并發原語的語言構建的服務，例如 Java 來說，每個請求對應一個線程則太浪費資源了，很快就會出 OOM 錯誤（OutOfMermoryError）。
創建和銷毀
Thread 創建和銷毀都會有巨大的消耗，因為要和操作系統打交道，是內核級的，通常解決的辦法就是線程池。而 goroutine 因為是由 Go runtime 負責管理的，創建和銷毀的消耗非常小，是用戶級。
切換
當 threads 切換時，需要保存各種寄存器，以便將來恢復：
16 general purpose registers, PC (Program Counter), SP (Stack Pointer), segment registers, 16 XMM registers, FP coprocessor state, 16 AVX registers, all MSRs etc.
而 goroutines 切換只需保存三個寄存器：Program Counter, Stack Pointer and BP。
一般而言，線程切換會消耗 1000-1500 納秒，一個納秒平均可以執行 12-18 條指令。所以由于線程切換，執行指令的條數會減少 12000-18000。
Goroutine 的切換約為 200 ns，相當于 2400-3600 條指令。
因此，goroutines 切換成本比 threads 要小得多。
M:N 模型
我們都知道，Go runtime 會負責 goroutine 的生老病死，從創建到銷毀，都一手包辦。Runtime 會在程序啟動的時候，創建 M 個線程（CPU 執行調度的單位），之后創建的 N 個 goroutine 都會依附在這 M 個線程上執行。這就是 M:N 模型：
在同一時刻，一個線程上只能跑一個 goroutine。當 goroutine 發生阻塞（例如上篇文章提到的向一個 channel 發送數據，被阻塞）時，runtime 會把當前 goroutine 調度走，讓其他 goroutine 來執行。目的就是不讓一個線程閑著，榨干 CPU 的每一滴油水。
什么是 scheduler
Go 程序的執行由兩層組成：Go Program，Runtime，即用戶程序和運行時。它們之間通過函數調用來實現內存管理、channel 通信、goroutines 創建等功能。用戶程序進行的系統調用都會被 Runtime 攔截，以此來幫助它進行調度以及垃圾回收相關的工作。
一個展現了全景式的關系如下圖：
為什么要 scheduler
Go scheduler 可以說是 Go 運行時的一個最重要的部分了。Runtime 維護所有的 goroutines，并通過 scheduler 來進行調度。Goroutines 和 threads 是獨立的，但是 goroutines 要依賴 threads 才能執行。
Go 程序執行的高效和 scheduler 的調度是分不開的。
scheduler 底層原理
實際上在操作系統看來，所有的程序都是在執行多線程。將 goroutines 調度到線程上執行，僅僅是 runtime 層面的一個概念，在操作系統之上的層面。
有三個基礎的結構體來實現 goroutines 的調度。g，m，p。
g 代表一個 goroutine，它包含：表示 goroutine 棧的一些字段，指示當前 goroutine 的狀態，指示當前運行到的指令地址，也就是 PC 值。
m 表示內核線程，包含正在運行的 goroutine 等字段。
p 代表一個虛擬的 Processor，它維護一個處于 Runnable 狀態的 g 隊列， m 需要獲得 p 才能運行 g。
當然還有一個核心的結構體：sched，它總覽全局。
Runtime 起始時會啟動一些 G：垃圾回收的 G，執行調度的 G，運行用戶代碼的 G；并且會創建一個 M 用來開始 G 的運行。隨著時間的推移，更多的 G 會被創建出來，更多的 M 也會被創建出來。
當然，在 Go 的早期版本，并沒有 p 這個結構體， m 必須從一個全局的隊列里獲取要運行的 g，因此需要獲取一個全局的鎖，當并發量大的時候，鎖就成了瓶頸。后來在大神 Dmitry Vyokov 的實現里，加上了 p 結構體。每個 p 自己維護一個處于 Runnable 狀態的 g 的隊列，解決了原來的全局鎖問題。
Go scheduler 的目標：
For scheduling goroutines onto kernel threads.
Go scheduler 的核心思想是：
reuse threads；
限制同時運行（不包含阻塞）的線程數為 N，N 等于 CPU 的核心數目；
線程私有的 runqueues，并且可以從其他線程 stealing goroutine 來運行，線程阻塞后，可以將 runqueues 傳遞給其他線程。
為什么需要 P 這個組件，直接把 runqueues 放到 M 不行嗎？
You might wonder now, why have contexts at all? Can't we just put the runqueues on the threads and get rid of contexts? Not really. The reason we have contexts is so that we can hand them off to other threads if the running thread needs to block for some reason.
An example of when we need to block, is when we call into a syscall. Since a thread cannot both be executing code and be blocked on a syscall, we need to hand off the context so it can keep scheduling.
翻譯一下，當一個線程阻塞的時候，將和它綁定的 P 上的 goroutines 轉移到其他線程。
Go scheduler 會啟動一個后臺線程 sysmon，用來檢測長時間（超過 10 ms）運行的 goroutine，將其調度到 global runqueues。這是一個全局的 runqueue，優先級比較低，以示懲罰。
總覽
通常講到 Go scheduler 都會提到 GPM 模型，我們來一個個地看。
下圖是我使用的 mac 的硬件信息，只有 2 個核。
但是配上 CPU 的超線程，1 個核可以變成 2 個，所以當我在 mac 上運行下面的程序時，會打印出 4。
func main() { // NumCPU 返回當前進程可以用到的邏輯核心數 fmt.Println(runtime.NumCPU()) }因為 NumCPU 返回的是邏輯核心數，而非物理核心數，所以最終結果是 4。
Go 程序啟動后，會給每個邏輯核心分配一個 P（Logical Processor）；同時，會給每個 P 分配一個 M（Machine，表示內核線程），這些內核線程仍然由 OS scheduler 來調度。
總結一下，當我在本地啟動一個 Go 程序時，會得到 4 個系統線程去執行任務，每個線程會搭配一個 P。
在初始化時，Go 程序會有一個 G（initial Goroutine），執行指令的單位。G 會在 M 上得到執行，內核線程是在 CPU 核心上調度，而 G 則是在 M 上進行調度。
G、P、M 都說完了，還有兩個比較重要的組件沒有提到：全局可運行隊列（GRQ）和本地可運行隊列（LRQ）。LRQ 存儲本地（也就是具體的 P）的可運行 goroutine，GRQ 存儲全局的可運行 goroutine，這些 goroutine 還沒有分配到具體的 P。
Go scheduler 是 Go runtime 的一部分，它內嵌在 Go 程序里，和 Go 程序一起運行。因此它運行在用戶空間，在 kernel 的上一層。和 Os scheduler 搶占式調度（preemptive）不一樣，Go scheduler 采用協作式調度（cooperating）。
Being a cooperating scheduler means the scheduler needs well-defined user space events that happen at safe points in the code to make scheduling decisions.
協作式調度一般會由用戶設置調度點，例如 python 中的 yield 會告訴 Os scheduler 可以將我調度出去了。
但是由于在 Go 語言里，goroutine 調度的事情是由 Go runtime 來做，并非由用戶控制，所以我們依然可以將 Go scheduler 看成是搶占式調度，因為用戶無法預測調度器下一步的動作是什么。
和線程類似，goroutine 的狀態也是三種（簡化版的）：
| Waiting | 等待狀態，goroutine 在等待某件事的發生。例如等待網絡數據、硬盤；調用操作系統 API；等待內存同步訪問條件 ready，如 atomic, mutexes |
| Runnable | 就緒狀態，只要給 M 我就可以運行 |
| Executing | 運行狀態。goroutine 在 M 上執行指令，這是我們想要的 |
下面這張 GPM 全局的運行示意圖見得比較多，可以留著，看完后面的系列文章之后再回頭來看，還是很有感觸的：
goroutine 調度時機
在四種情形下，goroutine 可能會發生調度，但也并不一定會發生，只是說 Go scheduler 有機會進行調度。
| 使用關鍵字?go | go 創建一個新的 goroutine，Go scheduler 會考慮調度 |
| GC | 由于進行 GC 的 goroutine 也需要在 M 上運行，因此肯定會發生調度。當然，Go scheduler 還會做很多其他的調度，例如調度不涉及堆訪問的 goroutine 來運行。GC 不管棧上的內存，只會回收堆上的內存 |
| 系統調用 | 當 goroutine 進行系統調用時，會阻塞 M，所以它會被調度走，同時一個新的 goroutine 會被調度上來 |
| 內存同步訪問 | atomic，mutex，channel 操作等會使 goroutine 阻塞，因此會被調度走。等條件滿足后（例如其他 goroutine 解鎖了）還會被調度上來繼續運行 |
work stealing
Go scheduler 的職責就是將所有處于 runnable 的 goroutines 均勻分布到在 P 上運行的 M。
當一個 P 發現自己的 LRQ 已經沒有 G 時，會從其他 P “偷” 一些 G 來運行。看看這是什么精神！自己的工作做完了，為了全局的利益，主動為別人分擔。這被稱為 Work-stealing，Go 從 1.1 開始實現。
Go scheduler 使用 M:N 模型，在任一時刻，M 個 goroutines（G） 要分配到 N 個內核線程（M），這些 M 跑在個數最多為 GOMAXPROCS 的邏輯處理器（P）上。每個 M 必須依附于一個 P，每個 P 在同一時刻只能運行一個 M。如果 P 上的 M 阻塞了，那它就需要其他的 M 來運行 P 的 LRQ 里的 goroutines。
個人感覺，上面這張圖比常見的那些用三角形表示 M，圓形表示 G，矩形表示 P 的那些圖更生動形象。
實際上，Go scheduler 每一輪調度要做的工作就是找到處于 runnable 的 goroutines，并執行它。找的順序如下：
runtime.schedule() { // only 1/61 of the time, check the global runnable queue for a G. // if not found, check the local queue. // if not found, // try to steal from other Ps. // if not, check the global runnable queue. // if not found, poll network. }找到一個可執行的 goroutine 后，就會一直執行下去，直到被阻塞。當 P2 上的一個 G 執行結束，它就會去 LRQ 獲取下一個 G 來執行。如果 LRQ 已經空了，就是說本地可運行隊列已經沒有 G 需要執行，并且這時 GRQ 也沒有 G 了。這時，P2 會隨機選擇一個 P（稱為 P1），P2 會從 P1 的 LRQ “偷”過來一半的 G。
這樣做的好處是，有更多的 P 可以一起工作，加速執行完所有的 G。
同步/異步系統調用
當 G 需要進行系統調用時，根據調用的類型，它所依附的 M 有兩種情況：同步和 異步。
對于同步的情況，M 會被阻塞，進而從 P 上調度下來，P 可不養閑人，G 仍然依附于 M。之后，一個新的 M 會被調用到 P 上，接著執行 P 的 LRQ 里嗷嗷待哺的 G 們。一旦系統調用完成，G 還會加入到 P 的 LRQ 里，M 則會被“雪藏”，待到需要時再“放”出來。
對于異步的情況，M 不會被阻塞，G 的異步請求會被“代理人” network poller 接手，G 也會被綁定到 network poller，等到系統調用結束，G 才會重新回到 P 上。M 由于沒被阻塞，它因此可以繼續執行 LRQ 里的其他 G。
可以看到，異步情況下，通過調度，Go scheduler 成功地將 I/O 的任務轉變成了 CPU 任務，或者說將內核級別的線程切換轉變成了用戶級別的 goroutine 切換，大大提高了效率。
The ability to turn IO/Blocking work into CPU-bound work at the OS level is where we get a big win in leveraging more CPU capacity over time.
Go scheduler 像一個非?？量痰谋O工一樣，不會讓一個 M 閑著，總是會通過各種辦法讓你干更多的事。
In Go, it’s possible to get more work done, over time, because the Go scheduler attempts to use less Threads and do more on each Thread, which helps to reduce load on the OS and the hardware.
scheduler 的陷阱
由于 Go 語言是協作式的調度，不會像線程那樣，在時間片用完后，由 CPU 中斷任務強行將其調度走。對于 Go 語言中運行時間過長的 goroutine，Go scheduler 有一個后臺線程在持續監控，一旦發現 goroutine 運行超過 10 ms，會設置 goroutine 的“搶占標志位”，之后調度器會處理。但是設置標志位的時機只有在函數“序言”部分，對于沒有函數調用的就沒有辦法了。
Golang implements a co-operative partially preemptive scheduler.
所以在某些極端情況下，會掉進一些陷阱。下面這個例子來自參考資料【scheduler 的陷阱】。
func main() { var x int threads := runtime.GOMAXPROCS(0) for i := 0; i < threads; i++ { go func() { for { x++ } }() } time.Sleep(time.Second) fmt.Println("x =", x) }運行結果是：在死循環里出不來，不會輸出最后的那條打印語句。
為什么？上面的例子會啟動和機器的 CPU 核心數相等的 goroutine，每個 goroutine 都會執行一個無限循環。
創建完這些 goroutines 后，main 函數里執行一條 time.Sleep(time.Second) 語句。Go scheduler 看到這條語句后，簡直高興壞了，要來活了。這是調度的好時機啊，于是主 goroutine 被調度走。先前創建的 threads 個 goroutines，剛好“一個蘿卜一個坑”，把 M 和 P 都占滿了。
在這些 goroutine 內部，又沒有調用一些諸如 channel， time.sleep 這些會引發調度器工作的事情。麻煩了，只能任由這些無限循環執行下去了。
解決的辦法也有，把 threads 減小 1：
func main() { var x int threads := runtime.GOMAXPROCS(0) - 1 for i := 0; i < threads; i++ { go func() { for { x++ } }() } time.Sleep(time.Second) fmt.Println("x =", x) }運行結果：
x = 0不難理解了吧，主 goroutine 休眠一秒后，被 go schduler 重新喚醒，調度到 M 上繼續執行，打印一行語句后，退出。主 goroutine 退出后，其他所有的 goroutine 都必須跟著退出。所謂“覆巢之下 焉有完卵”，一損俱損。
至于為什么最后打印出的 x 為 0，之前的文章《曹大談內存重排》里有講到過，這里不再深究了。
還有一種解決辦法是在 for 循環里加一句：
go func() { time.Sleep(time.Second) for { x++ } }()同樣可以讓 main goroutine 有機會調度執行。
總結
這篇文章，從宏觀角度來看 Go 調度器，講到了很多方面。接下來連續的 10 篇文章，我會深入源碼，層層解析。敬請期待！
參考資料里有很多篇英文博客寫得很好，當你掌握了基本原理后，看這些文章會有一種熟悉的感覺，講得真好！
參考資料
【知乎回答，怎樣理解阻塞非阻塞與同步異步的區別】？https://www.zhihu.com/question/19732473/answer/241673170【從零開始學架構 Reactor與Proactor】https://book.douban.com/subject/30335935/【思否上 goalng 排名第二的大佬譯文】https://segmentfault.com/a/1190000016038785【ardan labs】https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part1.html【論文 Analysis of the Go runtime scheduler】http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11DeshpandeSponslerWeissGO.pdf【譯文傳播很廣的】https://morsmachine.dk/go-scheduler【碼農翻身文章】https://mp.weixin.qq.com/s/BV25ngvWgbO3_yMK7eHhew【goroutine 資料合集】https://github.com/ardanlabs/gotraining/tree/master/topics/go/concurrency/goroutines【大彬調度器系列文章】http://lessisbetter.site/2019/03/10/golang-scheduler-1-history/【Scalable scheduler design doc 2012】https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw/edit#heading=h.rvfa6uqbq68u【Go scheduler blog post】https://morsmachine.dk/go-scheduler【work stealing】https://rakyll.org/scheduler/【Tony Bai 也談goroutine調度器】https://tonybai.com/2017/06/23/an-intro-about-goroutine-scheduler/【Tony Bai 調試實例分析】https://tonybai.com/2017/11/23/the-simple-analysis-of-goroutine-schedule-examples/【Tony Bai goroutine 是如何工作的】https://tonybai.com/2014/11/15/how-goroutines-work/【How Goroutines Work】https://blog.nindalf.com/posts/how-goroutines-work/【知乎回答 什么是阻塞，非阻塞，同步，異步？】https://www.zhihu.com/question/26393784/answer/328707302【知乎文章 完全理解同步/異步與阻塞/非阻塞】https://zhuanlan.zhihu.com/p/22707398【The Go netpoller】https://morsmachine.dk/netpoller【知乎專欄 Head First of Golang Scheduler】https://zhuanlan.zhihu.com/p/42057783【鳥窩 五種 IO 模型】https://colobu.com/2019/07/26/IO-models/【Go Runtime Scheduler】https://speakerdeck.com/retervision/go-runtime-scheduler?slide=32【go-scheduler】https://povilasv.me/go-scheduler/#【追蹤 scheduler】https://www.ardanlabs.com/blog/2015/02/scheduler-tracing-in-go.html【go tool trace 使用】https://making.pusher.com/go-tool-trace/【goroutine 之旅】https://medium.com/@riteeksrivastava/a-complete-journey-with-goroutines-8472630c7f5c【介紹?concurreny 和 parallelism 區別的視頻】https://www.youtube.com/watch?v=cN_DpYBzKso&t=422s【scheduler 的陷阱】http://www.sarathlakshman.com/2016/06/15/pitfall-of-golang-scheduler【boya 源碼閱讀】https://github.com/zboya/golangruntimereading/blob/master/src/runtime/proc.go【阿波張調度器系列教程】http://mp.weixin.qq.com/mp/homepage?_biz=MzU1OTg5NDkzOA==&hid=1&sn=8fc2b63f53559bc0cee292ce629c4788&scene=18#wechatredirect【曹大 asmshare】https://github.com/cch123/asmshare/blob/master/layout.md【Go調度器介紹和容易忽視的問題】https://www.cnblogs.com/CodeWithTxT/p/11370215.html【最近發現的一位大佬的源碼分析】https://github.com/changkun/go-under-the-hood/blob/master/book/zh-cn/TOC.md總結
以上是生活随笔為你收集整理的深度解密Go语言之scheduler的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 如何打造一份优雅的简历？
- 下一篇： 开天辟地 —— Go scheduler