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