Goroutine是Go語言原生支持併發的具體實現，你的Go代碼都無一例外地跑在goroutine中。你能夠啓動許多甚至成千上萬的goroutine，Go的runtime負責對goroutine進行管理。所謂的管理就是「調度」，粗糙地說調度就是決定什麼時候哪一個goroutine將得到資源開始執行、哪一個goroutine應該中止執行讓出資源、哪一個goroutine應該被喚醒恢復執行等。goroutine的調度是Go team care的事情，大多數gopher們無需關心。但我的以爲適當瞭解一下Goroutine的調度模型和原理，對於編寫出更好的go代碼是大有裨益的。所以，在這篇文章中，我將和你們一塊兒來探究一下goroutine調度器的演化以及模型/原理。nginx
注意：這裏要寫的並非對goroutine調度器的源碼分析，國內的雨痕老師在其《Go語言學習筆記》一書的下卷「源碼剖析」中已經對Go 1.5.1的scheduler實現作了細緻且高質量的源碼分析了，對Go scheduler的實現特別感興趣的gopher能夠移步到這本書中去^0^。這裏關於goroutine scheduler的介紹主要是參考了Go team有關scheduler的各類design doc、國外Gopher發表的有關scheduler的資料，固然雨痕老師的書也給我了不少的啓示。git
1、Goroutine調度器
提到「調度」，咱們首先想到的就是操做系統對進程、線程的調度。操做系統調度器會將系統中的多個線程按照必定算法調度到物理CPU上去運行。傳統的編程語言好比C、C++等的併發實現實際上就是基於操做系統調度的，即程序負責建立線程(通常經過pthread等lib調用實現)，操做系統負責調度。這種傳統支持併發的方式有諸多不足：程序員
-
複雜github
- 建立容易，退出難：作過C/C++ Programming的童鞋都知道，建立一個thread(好比利用pthread)雖然參數也很多，但好歹能夠接受。但一旦涉及到thread的退出，就要考慮thread是detached，仍是須要parent thread去join？是否須要在thread中設置cancel point，以保證join時能順利退出？
- 併發單元間通訊困難，易錯：多個thread之間的通訊雖然有多種機制可選，但用起來是至關複雜；而且一旦涉及到shared memory，就會用到各類lock，死鎖便成爲屢見不鮮；
- thread stack size的設定：是使用默認的，仍是設置的大一些，或者小一些呢？
-
難於scalinggolang
爲此，Go採用了用戶層輕量級thread或者說是類coroutine的概念來解決這些問題，Go將之稱爲」goroutine「。goroutine佔用的資源很是小(Go 1.4將每一個goroutine stack的size默認設置爲2k)，goroutine調度的切換也不用陷入(trap)操做系統內核層完成，代價很低。所以，一個Go程序中能夠建立成千上萬個併發的goroutine。全部的Go代碼都在goroutine中執行，哪怕是go的runtime也不例外。將這些goroutines按照必定算法放到「CPU」上執行的程序就稱爲goroutine調度器或goroutine scheduler。web
不過，一個Go程序對於操做系統來講只是一個用戶層程序，對於操做系統而言，它的眼中只有thread，它甚至不知道有什麼叫Goroutine的東西的存在。goroutine的調度全要靠Go本身完成，實現Go程序內goroutine之間「公平」的競爭「CPU」資源，這個任務就落到了Go runtime頭上，要知道在一個Go程序中，除了用戶代碼，剩下的就是go runtime了。算法
因而Goroutine的調度問題就演變爲go runtime如何將程序內的衆多goroutine按照必定算法調度到「CPU」資源上運行了。在操做系統層面，Thread競爭的「CPU」資源是真實的物理CPU，但在Go程序層面，各個Goroutine要競爭的」CPU」資源是什麼呢？Go程序是用戶層程序，它自己總體是運行在一個或多個操做系統線程上的，所以goroutine們要競爭的所謂「CPU」資源就是操做系統線程。這樣Go scheduler的任務就明確了：將goroutines按照必定算法放到不一樣的操做系統線程中去執行。這種在語言層面自帶調度器的，咱們稱之爲原生支持併發。編程
2、Go調度器模型與演化過程
一、G-M模型
2012年3月28日，Go 1.0正式發佈。在這個版本中，Go team實現了一個簡單的調度器。在這個調度器中，每一個goroutine對應於runtime中的一個抽象結構：G，而os thread做爲「物理CPU」的存在而被抽象爲一個結構：M(machine)。這個結構雖然簡單，可是卻存在着許多問題。前Intel blackbelt工程師、現Google工程師Dmitry Vyukov在其《Scalable Go Scheduler Design》一文中指出了G-M模型的一個重要不足： 限制了Go併發程序的伸縮性，尤爲是對那些有高吞吐或並行計算需求的服務程序。主要體如今以下幾個方面：c#
- 單一全局互斥鎖(Sched.Lock)和集中狀態存儲的存在致使全部goroutine相關操做，好比：建立、從新調度等都要上鎖；
- goroutine傳遞問題：M常常在M之間傳遞」可運行」的goroutine，這致使調度延遲增大以及額外的性能損耗；
- 每一個M作內存緩存，致使內存佔用太高，數據局部性較差；
- 因爲syscall調用而造成的劇烈的worker thread阻塞和解除阻塞，致使額外的性能損耗。
二、G-P-M模型
因而Dmitry Vyukov親自操刀改進Go scheduler，在Go 1.1中實現了G-P-M調度模型和work stealing算法，這個模型一直沿用至今：
有名人曾說過：「計算機科學領域的任何問題均可以經過增長一個間接的中間層來解決」，我以爲Dmitry Vyukov的G-P-M模型恰是這一理論的踐行者。Dmitry Vyukov經過向G-M模型中增長了一個P，實現了Go scheduler的scalable。
P是一個「邏輯Proccessor」，每一個G要想真正運行起來，首先須要被分配一個P（進入到P的local runq中，這裏暫忽略global runq那個環節）。對於G來講，P就是運行它的「CPU」，能夠說：G的眼裏只有P。但從Go scheduler視角來看，真正的「CPU」是M，只有將P和M綁定才能讓P的runq中G得以真實運行起來。這樣的P與M的關係，就比如Linux操做系統調度層面用戶線程(user thread)與核心線程(kernel thread)的對應關係那樣(N x M)。
三、搶佔式調度
G-P-M模型的實現算是Go scheduler的一大進步，但Scheduler仍然有一個頭疼的問題，那就是不支持搶佔式調度，致使一旦某個G中出現死循環或永久循環的代碼邏輯，那麼G將永久佔用分配給它的P和M，位於同一個P中的其餘G將得不到調度，出現「餓死」的狀況。更爲嚴重的是，當只有一個P時(GOMAXPROCS=1)時，整個Go程序中的其餘G都將「餓死」。因而Dmitry Vyukov又提出了《Go Preemptive Scheduler Design》並在Go 1.2中實現了「搶佔式」調度。
這個搶佔式調度的原理則是在每一個函數或方法的入口，加上一段額外的代碼，讓runtime有機會檢查是否須要執行搶佔調度。這種解決方案只能說局部解決了「餓死」問題，對於沒有函數調用，純算法循環計算的G，scheduler依然沒法搶佔。
四、NUMA調度模型
從Go 1.2之後，Go彷佛將重點放在了對GC的低延遲的優化上了，對scheduler的優化和改進彷佛不那麼熱心了，只是伴隨着GC的改進而做了些小的改動。Dmitry Vyukov在2014年9月提出了一個新的proposal design doc：《NUMA‐aware scheduler for Go》，做爲將來Go scheduler演進方向的一個提議，不過至今彷佛這個proposal也沒有列入開發計劃。
五、其餘優化
Go runtime已經實現了netpoller，這使得即使G發起網絡I/O操做也不會致使M被阻塞（僅阻塞G），從而不會致使大量M被建立出來。可是對於regular file的I/O操做一旦阻塞，那麼M將進入sleep狀態，等待I/O返回後被喚醒；這種狀況下P將與sleep的M分離，再選擇一個idle的M。若是此時沒有idle的M，則會新建立一個M，這就是爲什麼大量I/O操做致使大量Thread被建立的緣由。
Ian Lance Taylor在Go 1.9 dev週期中增長了一個Poller for os package的功能，這個功能能夠像netpoller那樣，在G操做支持pollable的fd時，僅阻塞G，而不阻塞M。不過該功能依然不能對regular file有效，regular file不是pollable的。不過，對於scheduler而言，這也算是一個進步了。
3、Go調度器原理的進一步理解
一、G、P、M
關於G、P、M的定義，你們能夠參見$GOROOT/src/runtime/runtime2.go這個源文件。這三個struct都是大塊兒頭，每一個struct定義都包含十幾個甚至2、三十個字段。像scheduler這樣的核心代碼向來很複雜，考慮的因素也很是多，代碼「耦合」成一坨。不過從複雜的代碼中，咱們依然能夠看出來G、P、M的各自大體用途（固然雨痕老師的源碼分析功不可沒），這裏簡要說明一下：
- G: 表示goroutine，存儲了goroutine的執行stack信息、goroutine狀態以及goroutine的任務函數等；另外G對象是能夠重用的。
- P: 表示邏輯processor，P的數量決定了系統內最大可並行的G的數量（前提：系統的物理cpu核數>=P的數量）；P的最大做用仍是其擁有的各類G對象隊列、鏈表、一些cache和狀態。
- M: M表明着真正的執行計算資源。在綁定有效的p後，進入schedule循環；而schedule循環的機制大體是從各類隊列、p的本地隊列中獲取G，切換到G的執行棧上並執行G的函數，調用goexit作清理工做並回到m，如此反覆。M並不保留G狀態，這是G能夠跨M調度的基礎。
下面是G、P、M定義的代碼片斷：
//src/runtime/runtime2.go
type g struct {
stack stack // offset known to runtime/cgo
sched gobuf
goid int64
gopc uintptr // pc of go statement that created this goroutine
startpc uintptr // pc of goroutine function
... ...
}
type p struct {
lock mutex
id int32
status uint32 // one of pidle/prunning/...
mcache *mcache
racectx uintptr
// Queue of runnable goroutines. Accessed without lock.
runqhead uint32
runqtail uint32
runq [256]guintptr
runnext guintptr
// Available G's (status == Gdead)
gfree *g
gfreecnt int32
... ...
}
type m struct {
g0 *g // goroutine with scheduling stack
mstartfn func()
curg *g // current running goroutine
.... ..
}
二、G被搶佔調度
和操做系統按時間片調度線程不一樣，Go並無時間片的概念。若是某個G沒有進行system call調用、沒有進行I/O操做、沒有阻塞在一個channel操做上，那麼m是如何讓G停下來並調度下一個runnable G的呢？答案是：G是被搶佔調度的。
前面說過，除非極端的無限循環或死循環，不然只要G調用函數，Go runtime就有搶佔G的機會。Go程序啓動時，runtime會去啓動一個名爲sysmon的m(通常稱爲監控線程)，該m無需綁定p便可運行，該m在整個Go程序的運行過程當中相當重要：
//$GOROOT/src/runtime/proc.go
// The main goroutine.
func main() {
... ...
systemstack(func() {
newm(sysmon, nil)
})
.... ...
}
// Always runs without a P, so write barriers are not allowed.
//
//go:nowritebarrierrec
func sysmon() {
// If a heap span goes unused for 5 minutes after a garbage collection,
// we hand it back to the operating system.
scavengelimit := int64(5 * 60 * 1e9)
... ...
if .... {
... ...
// retake P's blocked in syscalls
// and preempt long running G's
if retake(now) != 0 {
idle = 0
} else {
idle++
}
... ...
}
}
sysmon每20us~10ms啓動一次，按照《Go語言學習筆記》中的總結，sysmon主要完成以下工做：
- 釋放閒置超過5分鐘的span物理內存；
- 若是超過2分鐘沒有垃圾回收，強制執行；
- 將長時間未處理的netpoll結果添加到任務隊列；
- 向長時間運行的G任務發出搶佔調度；
- 收回因syscall長時間阻塞的P；
咱們看到sysmon將「向長時間運行的G任務發出搶佔調度」，這個事情由retake實施：
// forcePreemptNS is the time slice given to a G before it is
// preempted.
const forcePreemptNS = 10 * 1000 * 1000 // 10ms
func retake(now int64) uint32 {
... ...
// Preempt G if it's running for too long.
t := int64(_p_.schedtick)
if int64(pd.schedtick) != t {
pd.schedtick = uint32(t)
pd.schedwhen = now
continue
}
if pd.schedwhen+forcePreemptNS > now {
continue
}
preemptone(_p_)
... ...
}
能夠看出，若是一個G任務運行10ms，sysmon就會認爲其運行時間過久而發出搶佔式調度的請求。一旦G的搶佔標誌位被設爲true，那麼待這個G下一次調用函數或方法時，runtime即可以將G搶佔，並移出運行狀態，放入P的local runq中，等待下一次被調度。
三、channel阻塞或network I/O狀況下的調度
若是G被阻塞在某個channel操做或network I/O操做上時，G會被放置到某個wait隊列中，而M會嘗試運行下一個runnable的G；若是此時沒有runnable的G供m運行，那麼m將解綁P，並進入sleep狀態。當I/O available或channel操做完成，在wait隊列中的G會被喚醒，標記爲runnable，放入到某P的隊列中，綁定一個M繼續執行。
四、system call阻塞狀況下的調度
若是G被阻塞在某個system call操做上，那麼不光G會阻塞，執行該G的M也會解綁P(實質是被sysmon搶走了)，與G一塊兒進入sleep狀態。若是此時有idle的M，則P與其綁定繼續執行其餘G；若是沒有idle M，但仍然有其餘G要去執行，那麼就會建立一個新M。
當阻塞在syscall上的G完成syscall調用後，G會去嘗試獲取一個可用的P，若是沒有可用的P，那麼G會被標記爲runnable，以前的那個sleep的M將再次進入sleep。
4、調度器狀態的查看方法
Go提供了調度器當前狀態的查看方法：使用Go運行時環境變量GODEBUG。
$GODEBUG=schedtrace=1000 godoc -http=:6060 SCHED 0ms: gomaxprocs=4 idleprocs=3 threads=3 spinningthreads=0 idlethreads=0 runqueue=0 [0 0 0 0] SCHED 1001ms: gomaxprocs=4 idleprocs=0 threads=9 spinningthreads=0 idlethreads=3 runqueue=2 [8 14 5 2] SCHED 2006ms: gomaxprocs=4 idleprocs=0 threads=25 spinningthreads=0 idlethreads=19 runqueue=12 [0 0 4 0] SCHED 3006ms: gomaxprocs=4 idleprocs=0 threads=26 spinningthreads=0 idlethreads=8 runqueue=2 [0 1 1 0] SCHED 4010ms: gomaxprocs=4 idleprocs=0 threads=26 spinningthreads=0 idlethreads=20 runqueue=12 [6 3 1 0] SCHED 5010ms: gomaxprocs=4 idleprocs=0 threads=26 spinningthreads=1 idlethreads=20 runqueue=17 [0 0 0 0] SCHED 6016ms: gomaxprocs=4 idleprocs=0 threads=26 spinningthreads=0 idlethreads=20 runqueue=1 [3 4 0 10] ... ...
GODEBUG這個Go運行時環境變量非常強大，經過給其傳入不一樣的key1=value1,key2=value2… 組合，Go的runtime會輸出不一樣的調試信息，好比在這裏咱們給GODEBUG傳入了」schedtrace=1000″，其含義就是每1000ms，打印輸出一次goroutine scheduler的狀態，每次一行。每一行各字段含義以下：
以上面例子中最後一行爲例： SCHED 6016ms: gomaxprocs=4 idleprocs=0 threads=26 spinningthreads=0 idlethreads=20 runqueue=1 [3 4 0 10] SCHED：調試信息輸出標誌字符串，表明本行是goroutine scheduler的輸出； 6016ms：即從程序啓動到輸出這行日誌的時間； gomaxprocs: P的數量； idleprocs: 處於idle狀態的P的數量；經過gomaxprocs和idleprocs的差值，咱們就可知道執行go代碼的P的數量； threads: os threads的數量，包含scheduler使用的m數量，加上runtime自用的相似sysmon這樣的thread的數量； spinningthreads: 處於自旋狀態的os thread數量； idlethread: 處於idle狀態的os thread的數量； runqueue=1： go scheduler全局隊列中G的數量； [3 4 0 10]: 分別爲4個P的local queue中的G的數量。
咱們還能夠輸出每一個goroutine、m和p的詳細調度信息，但對於Go user來講，絕大多數時間這是沒必要要的：
$ GODEBUG=schedtrace=1000,scheddetail=1 godoc -http=:6060 SCHED 0ms: gomaxprocs=4 idleprocs=3 threads=3 spinningthreads=0 idlethreads=0 runqueue=0 gcwaiting=0 nmidlelocked=0 stopwait=0 sysmonwait=0 P0: status=1 schedtick=0 syscalltick=0 m=0 runqsize=0 gfreecnt=0 P1: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P2: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P3: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 M2: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=1 dying=0 helpgc=0 spinning=false blocked=false lockedg=-1 M1: p=-1 curg=17 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=false lockedg=17 M0: p=0 curg=1 mallocing=0 throwing=0 preemptoff= locks=1 dying=0 helpgc=0 spinning=false blocked=false lockedg=1 G1: status=8() m=0 lockedm=0 G17: status=3() m=1 lockedm=1 SCHED 1002ms: gomaxprocs=4 idleprocs=0 threads=13 spinningthreads=0 idlethreads=7 runqueue=6 gcwaiting=0 nmidlelocked=0 stopwait=0 sysmonwait=0 P0: status=2 schedtick=2293 syscalltick=18928 m=-1 runqsize=12 gfreecnt=2 P1: status=1 schedtick=2356 syscalltick=19060 m=11 runqsize=11 gfreecnt=0 P2: status=2 schedtick=2482 syscalltick=18316 m=-1 runqsize=37 gfreecnt=1 P3: status=2 schedtick=2816 syscalltick=18907 m=-1 runqsize=2 gfreecnt=4 M12: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=true lockedg=-1 M11: p=1 curg=6160 mallocing=0 throwing=0 preemptoff= locks=2 dying=0 helpgc=0 spinning=false blocked=false lockedg=-1 M10: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=true lockedg=-1 ... ... SCHED 2002ms: gomaxprocs=4 idleprocs=0 threads=23 spinningthreads=0 idlethreads=5 runqueue=4 gcwaiting=0 nmidlelocked=0 stopwait=0 sysmonwait=0 P0: status=0 schedtick=2972 syscalltick=29458 m=-1 runqsize=0 gfreecnt=6 P1: status=2 schedtick=2964 syscalltick=33464 m=-1 runqsize=0 gfreecnt=39 P2: status=1 schedtick=3415 syscalltick=33283 m=18 runqsize=0 gfreecnt=12 P3: status=2 schedtick=3736 syscalltick=33701 m=-1 runqsize=1 gfreecnt=6 M22: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=true lockedg=-1 M21: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=true lockedg=-1 ... ...
關於go scheduler調試信息輸出的詳細信息，能夠參考Dmitry Vyukov的大做：《Debugging performance issues in Go programs》。這也應該是每一個gopher必讀的經典文章。固然更詳盡的代碼可參考$GOROOT/src/runtime/proc.go中的schedtrace函數。
基礎
Go運行時管理調度、垃圾收集和goroutines的運行時環境。在這裏，我將只關注調度程序。
運行時調度器經過將它們映射到操做系統線程來運行goroutines。Goroutines是線程的輕量級版本，啓動成本很是低。每個goroutine都是由一個名爲G的結構體描述的，它包含了跟蹤其堆棧和當前狀態所必需的字段。因此,G = goroutine。
運行時跟蹤每一個G，並將它們映射到邏輯處理器上，命名爲P。P能夠被看做是一個抽象的資源或上下文，須要被獲取，所以OS線程（稱爲M或機器）能夠執行G。你能夠經過調用 runtime.GOMAXPROCS(numLogicalProcessors) 來控制運行時的邏輯處理器，若是你打算調整這個參數（或許不該該），設置一次並忘記它，由於它須要「中止一切」GC暫停。
從本質上講，操做系統運行線程，執行你的代碼。Go的訣竅是，編譯器在不一樣的地方插入調用到Go運行時，例如經過通道發送一個值，對運行時包進行調用），這樣就能夠通知調度程序並採起行動。
Ms，Ps&Gs之間的互動
Ms、Ps和Gs之間的交互有點複雜。看一下這個工做流程圖：
在這裏咱們能夠看到，對於G來講有兩種類型的隊列：在「schedt」結構中有一個全局隊列（不多使用），而且每一個P維護一個可運行的G隊列。
爲了執行一個goroutine，M須要保存上下文P.機器，而後彈出它的goroutines，執行代碼。
當你安排一個新的goroutine（作一個go func（）調用）時，它被放置到P的隊列中。這裏有一個有趣的偷工調度算法，當M完成了某個G的執行，而後它試圖從隊列中取出另外一個G，它是空的，而後它隨機地選擇另外一個P並試圖從它中偷取一半的可運行的G！
當你的goroutine作一個阻塞的系統調用時，會發生一些有趣的事情。阻塞系統調用將被攔截，若是要運行Gs，運行時將從P中分離出線程並建立一個新的OS線程（若是空閒線程不存在的話）來服務該處理器。
當一個系統調用恢復時，goroutine被放回一個本地運行隊列，線程會自動放置（意味着線程不會運行），並將本身插入到空閒線程列表中。
若是goroutine進行網絡調用，運行時也會執行相似的操做。這個調用將被攔截，可是由於Go有一個集成的網絡輪詢器，它有本身的線程，它將被分配給它。
若是當前的goroutine被阻塞，那麼運行時將運行一個不一樣的goroutine：
-
阻塞系統調用（例如打開一個文件），
-
網絡輸入，
-
通道操做，
-
同步包中的原語。
調度程序跟蹤
Go容許跟蹤運行時調度程序。這是經過GODEBUG環境變量完成的：
$ GODEBUG=scheddetail=1,schedtrace=1000 ./program
下面是它給出的輸出示例：
SCHED 0ms: gomaxprocs=8 idleprocs=7 threads=2 spinningthreads=0 idlethreads=0 runqueue=0 gcwaiting=0 nmidlelocked=0 stopwait=0 sysmonwait=0 P0: status=1 schedtick=0 syscalltick=0 m=0 runqsize=0 gfreecnt=0 P1: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P2: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P3: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P4: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P5: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P6: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 P7: status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0 M1: p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=1 dying=0 helpgc=0 spinning=false blocked=false lockedg=-1 M0: p=0 curg=1 mallocing=0 throwing=0 preemptoff= locks=1 dying=0 helpgc=0 spinning=false blocked=false lockedg=1 G1: status=8() m=0 lockedm=0
注意，它使用了與G、M和P以及它們的狀態相同的概念，好比P的隊列大小。一般，你不須要那麼多的細節，因此你可使用：
$ GODEBUG=schedtrace=1000 ./program
此外，還有一個名爲go tool trace的高級工具，它有一個UI，容許咱們探索，程序運行時正在作什麼。
MPG畫圖示意
調度模型簡介
groutine能擁有強大的併發實現是經過GPM調度模型實現，下面就來解釋下goroutine的調度模型。
Go的調度器內部有四個重要的結構：M，P，S，Sched，如上圖所示（Sched未給出）
M:M表明內核級線程，一個M就是一個線程，goroutine就是跑在M之上的；M是一個很大的結構，裏面維護小對象內存cache（mcache）、當前執行的goroutine、隨機數發生器等等很是多的信息
G:表明一個goroutine，它有本身的棧，instruction pointer和其餘信息（正在等待的channel等等），用於調度。
P:P全稱是Processor，處理器，它的主要用途就是用來執行goroutine的，因此它也維護了一個goroutine隊列，裏面存儲了全部須要它來執行的goroutine Sched：表明調度器，它維護有存儲M和G的隊列以及調度器的一些狀態信息等。
調度實現
從上圖中看，有2個物理線程M，每個M都擁有一個處理器P，每個也都有一個正在運行的goroutine。
P的數量能夠經過GOMAXPROCS()來設置，它其實也就表明了真正的併發度，即有多少個goroutine能夠同時運行。
圖中灰色的那些goroutine並無運行，而是出於ready的就緒態，正在等待被調度。P維護着這個隊列（稱之爲runqueue），
Go語言裏，啓動一個goroutine很容易：go function 就行，因此每有一個go語句被執行，runqueue隊列就在其末尾加入一個
goroutine，在下一個調度點，就從runqueue中取出（如何決定取哪一個goroutine？）一個goroutine執行。
當一個OS線程M0陷入阻塞時（以下圖)，P轉而在運行M1，圖中的M1多是正被建立，或者從線程緩存中取出。
當MO返回時，它必須嘗試取得一個P來運行goroutine，通常狀況下，它會從其餘的OS線程那裏拿一個P過來，
若是沒有拿到的話，它就把goroutine放在一個global runqueue裏，而後本身睡眠（放入線程緩存裏）。全部的P也會週期性的檢查global runqueue並運行其中的goroutine，不然global runqueue上的goroutine永遠沒法執行。 另外一種狀況是P所分配的任務G很快就執行完了（分配不均），這就致使了這個處理器P很忙，可是其餘的P還有任務，此時若是global runqueue沒有任務G了，那麼P不得不從其餘的P裏拿一些G來執行。通常來講，若是P從其餘的P那裏要拿任務的話，通常就拿run queue的一半，這就確保了每一個OS線程都能充分的使用，以下圖：
參考地址：
http://morsmachine.dk/go-scheduler