原文： http://morsmachine.dk/go-scheduler
為什么在內(nèi)核的線程調(diào)度器之外Go還需要一個自己的調(diào)度器？
- POSIX線程API是對已有的UNIX進程模型的邏輯擴展，因此線程和進程在很多方面都類似。例如，線程有自己的信號掩碼，CPU affinity（進程要在某個給定的 CPU 上盡量長時間地運行而不被遷移到其他處理器的傾向性），cgroups。但是有很多特性對于Go程序來說都是累贅。 2. 另外一個問題是基于Go語言模型，OS的調(diào)度決定并不一定合理。例如，Go的垃圾回收需要內(nèi)存處于一致性的狀態(tài)，這需要所有運行的線程都停止。垃圾回收的時間點是不確定的，如果僅由OS來調(diào)度，將會由大量的線程停止工作。
- 單獨開發(fā)一個Go的調(diào)度器能讓我們知道什么時候內(nèi)存處于一致性的狀態(tài)。也就是說，當(dāng)開始垃圾回收時，運行時只需要為當(dāng)時正在CPU核上運行的那個線程等待即可，而不是等待所有的線程。
線程模型——高級語言對內(nèi)核線程的封裝實現(xiàn)
- N:1模型，N個用戶空間線程在1個內(nèi)核空間線程上運行。優(yōu)勢是上下文切換非?？斓菬o法利用多核系統(tǒng)的優(yōu)點。
- 1:1模型，1個內(nèi)核空間線程運行一個用戶空間線程。這種充分利用了多核系統(tǒng)的優(yōu)勢但是上下文切換非常慢，因為每一次調(diào)度都會在用戶態(tài)和內(nèi)核態(tài)之間切換。（POSIX線程模型(pthread)，Java）
- M:N模型， 每個用戶線程對應(yīng)多個內(nèi)核空間線程，同時也可以一個內(nèi)核空間線程對應(yīng)多個用戶空間線程。Go打算采用這種模型，使用任意個內(nèi)核模型管理任意個goroutine。這樣結(jié)合了以上兩種模型的優(yōu)點，但缺點就是調(diào)度的復(fù)雜性。
Golang的調(diào)度器實現(xiàn)
Go的調(diào)度器使用了三種結(jié)構(gòu)：M，P，S
- M代表內(nèi)核線程，類似于標(biāo)準(zhǔn)的POSIX線程，M代表machine。
- G代表goroutine，它擁有自己的棧，程序計數(shù)器（instruction counter）和一些關(guān)于goroutine調(diào)度的信息（如正在阻塞的channel）。
- P代表processor，表示調(diào)度的上下文?？梢园阉醋魇且粋€局部的調(diào)度器，讓Go代碼跑在一個單獨的線程上。這是讓Go從一個N:1調(diào)度器映射到一個M:N調(diào)度器的關(guān)鍵。
如上圖所示，每個線程運行了一個goroutine，所以必須得維持一個上下文P。
上下文的數(shù)量由啟動時環(huán)境變量$GOMAXPROCS或者是由runtime的方法GOMAXPROCS()決定（默認(rèn)值為1，Go1.5以后默認(rèn)值為CPU的核心數(shù)）。這意味著在程序執(zhí)行的任意時刻都只有$GOMAXPROCS個goroutine在同時運行。
灰色的goroutine沒有在運行，等待被調(diào)度。它們被維護在一個隊列（runqueues）里。當(dāng)一個go語句執(zhí)行，就將一個新的goroutine添加到隊列尾；當(dāng)運行當(dāng)前goroutine到調(diào)度點時，就從隊列中彈出一個新的goroutine。
每一個context擁有一個局部的runqueue。之前版本的Go調(diào)度器只有一個全局的帶有互斥鎖的runqueue，這樣線程經(jīng)常被阻塞等待其它線程解鎖，在多核機器上性能表現(xiàn)及其差。
之所以要維護多個context，是因為當(dāng)一個OS線程被阻塞時，我們可以把contex移到其它的線程中去。
如上圖所示，當(dāng)一個內(nèi)核線程M0要被阻塞時，P將會去M1上繼續(xù)運行。Go的調(diào)度器保證了擁有足夠的線程跑所有的contexts。因為還有在執(zhí)行的goroutine，M0會暫時掛起。當(dāng)syscall返回時，M0會嘗試獲取一個context來運行G0。一般情況下，它會從其它內(nèi)核線程偷一個過來。如果沒有偷到，它會把G0放到一個全局的runqueue內(nèi)，將自己放回線程池，進入睡眠狀態(tài)。
當(dāng)contexts運行完所有的本地runqueue時，它會從全局runqueue拉取goroutine。contexts也會周期性檢查全局runqueue是否存在goroutine，以防止全局runqueue中的goroutine餓死。
這就是為什么Go程序多線程運行的原因，即使GOMAXPROCS只有1。
另外一種情況就是某個context的goroutine運行完了，全局runqueue也沒有了goroutine，而其它context還有大量goroutine需要運行。這時候就需要從其它的地方獲取goroutine。如圖所示，context會嘗試從其它context的runqueue里面偷一半的goroutine。這樣就能確保所有的線程都能以最大負(fù)荷運行。
