go 調度機制簡介

goroutine是go中最重要的功能之一，正是由於有了goroutine這樣強大的工具，go在併發方面表現的特別優秀。

那麼goroutine和普通的線程和協程有什麼區別呢？首先，咱們須要明白線程和協程的區別，線程是內核態的，而協程是用戶態的。什麼意思呢？就是說線程之間的切換主要由內核去調度，而協程之間的切換則須要用戶去操做。線程切換須要保存上下文信息，切換到另外一個線程，過段時間，恢復到以前的線程繼續執行。cpu時間片的讓渡，上下文的保存等等複雜操做都是由內核實現的，程序員不須要關注其中的細節。對程序員更加友好。可是爲了支持這些操做，線程須要使用大量的資源。因此一個進程之間只能支持少許的線程，通常幾個，十幾個就會將資源耗盡。而協程則不一樣，它將協程之間的調度交給程序員去處理，優秀的程序員能夠經過各類操做下降協程之間上下文切換資源佔用，處理切換時機等等。對程序員的水平要求更高，因爲調度由用戶控制，那麼使用的資源相對來講會更少，因此一個進程能夠啓動的協程數量比線程更多。

goroutine結合了線程和協程的優勢。主要表如今，從資源佔用上看，goroutine更像是協程，佔用的資源都不多，支持一個進程開千個萬個goroutine。而從切換角度來看，goroutine更像是線程，不須要用戶實現goroutine之間的調度。goroutine之間的調度不禁內核來操做，也不禁用戶操做。由go本身來操做，go中本身實現了調度器。

簡單的說，goroutine既擁有協程的優勢，對系統資源的佔用低，又擁有線程的優勢，用戶不須要實現協程的調度。只須要學習如何使用go自身的調度器便可。

goroutine中很重要的一個概念是

不要經過共享內存來通訊，要經過通訊來共享內存

經過通訊來共享內存，下降了對內存的佔用，go中使用channel通道來實現通訊。這裏不詳細解釋。

咱們主要介紹下go 的調度機制，學會了go的調度機制，能夠幫助咱們學習和理解如何正確使用goroutine，定位和解決goroutine中出現的問題。

整個調度模型由 Goroutine/Processor/Machine 以及全局調度信息 sched 組成。

上述是我的的理解，有不正確的地方歡迎指出。

調度機制已經有不少人寫了，寫的也很簡單明瞭，就直接轉載過來。後面有時間會去閱讀源碼，若是下面的某些闡述與源碼有衝突，後續會改正。

GO併發模型的實現原理

咱們先從線程講起，不管語言層面何種併發模型，到了操做系統層面，必定是以線程的形態存在的。而操做系統根據資源訪問權限的不一樣，體系架構可分爲用戶空間和內核空間；內核空間主要操做訪問CPU資源、I/O資源、內存資源等硬件資源，爲上層應用程序提供最基本的基礎資源，用戶空間呢就是上層應用程序的固定活動空間，用戶空間不能夠直接訪問資源，必須經過「系統調用」、「庫函數」或「Shell腳本」來調用內核空間提供的資源。

咱們如今的計算機語言，能夠狹義的認爲是一種「軟件」，它們中所謂的「線程」，每每是用戶態的線程，和操做系統自己內核態的線程（簡稱KSE），仍是有區別的。

線程模型的實現，能夠分爲如下幾種方式：

用戶級線程模型

 

如圖所示，多個用戶態的線程對應着一個內核線程，程序線程的建立、終止、切換或者同步等線程工做必須自身來完成。它能夠作快速的上下文切換。缺點是不能有效利用多核CPU。

內核級線程模型

 

這種模型直接調用操做系統的內核線程，全部線程的建立、終止、切換、同步等操做，都由內核來完成。一個用戶態的線程對應一個系統線程，它能夠利用多核機制，但上下文切換須要消耗額外的資源。C++就是這種。

兩級線程模型

 

這種模型是介於用戶級線程模型和內核級線程模型之間的一種線程模型。這種模型的實現很是複雜，和內核級線程模型相似，一個進程中能夠對應多個內核級線程，可是進程中的線程不和內核線程一一對應；這種線程模型會先建立多個內核級線程，而後用自身的用戶級線程去對應建立的多個內核級線程，自身的用戶級線程須要自己程序去調度，內核級的線程交給操做系統內核去調度。

M個用戶線程對應N個系統線程，缺點增長了調度器的實現難度。

Go語言的線程模型就是一種特殊的兩級線程模型（GPM調度模型）。

以上轉載自https://www.jianshu.com/p/4afa0679851d

調度器

主要基於三個基本對象上，G，M，P（定義在源碼的src/runtime/runtime.h文件中）

1.     G表明一個goroutine對象，每次go調用的時候，都會建立一個G對象

2.     M表明一個線程，每次建立一個M的時候，都會有一個底層線程建立；全部的G任務，最終仍是在M上執行

3.     P表明一個處理器，每個運行的M都必須綁定一個P，就像線程必須在麼一個CPU核上執行同樣

P的個數就是GOMAXPROCS（最大256），啓動時固定的，通常不修改； M的個數和P的個數不必定同樣多（會有休眠的M或者不須要太多的M）（最大10000）；每個P保存着本地G任務隊列，也有一個全局G任務隊列；

全局G任務隊列會和各個本地G任務隊列按照必定的策略互相交換（滿了，則把本地隊列的一半送給全局隊列）

P是用一個全局數組（255）來保存的，而且維護着一個全局的P空閒鏈表

每次go調用的時候，都會：

1.     建立一個G對象，加入到本地隊列或者全局隊列

2.     若是還有空閒的P，則建立一個M

3.     M會啓動一個底層線程，循環執行能找到的G任務

4.     G任務的執行順序是，先從本地隊列找，本地沒有則從全局隊列找（一次性轉移(全局G個數/P個數）個，再去其它P中找（一次性轉移一半），

5.     以上的G任務執行是按照隊列順序（也就是go調用的順序）執行的。

對於上面的第2-3步，建立一個M，其過程：

1.     先找到一個空閒的P，若是沒有則直接返回，（這個地方就保證了進程不會佔用超過本身設定的cpu個數）

2.     調用系統api建立線程，不一樣的操做系統，調用不同，其實就是和c語言建立過程是一致的，（windows用的是CreateThread，linux用的是clone系統調用）

3.     而後建立的這個線程裏面纔是真正作事的，循環執行G任務

那就會有個問題，若是一個系統調用或者G任務執行太長，他就會一直佔用這個線程，因爲本地隊列的G任務是順序執行的，其它G任務就會阻塞了，怎樣停止長任務的呢？

這樣滴，啓動的時候，會專門建立一個線程sysmon，用來監控和管理，在內部是一個循環：

1.     記錄全部P的G任務計數schedtick，（schedtick會在每執行一個G任務後遞增）

2.     若是檢查到 schedtick一直沒有遞增，說明這個P一直在執行同一個G任務，若是超過必定的時間（10ms），就在這個G任務的棧信息裏面加一個標記

3.     而後這個G任務在執行的時候，若是遇到非內聯函數調用，就會檢查一次這個標記，而後中斷本身，把本身加到隊列末尾，執行下一個G

4.     若是沒有遇到非內聯函數（有時候正常的小函數會被優化成內聯函數）調用的話，那就慘了，會一直執行這個G任務，直到它本身結束；若是是個死循環，而且GOMAXPROCS=1的話，程序會掛死。

對於一個G任務，中斷後的恢復過程：

1.     中斷的時候將寄存器裏的棧信息，保存到本身的G對象裏面

2.     當再次輪到本身執行時，將本身保存的棧信息複製到寄存器裏面，這樣就接着上次以後運行了。
————————————————
版權聲明：本文爲CSDN博主「正版兩隻羊」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。
原文連接：https://blog.csdn.net/liangzhiyang/article/details/52669851

總結，執行go程序時，從main開始，main goroutine建立一個新的M,綁定一個P。若是main函數裏有其餘的goroutine，查詢是否有空閒的P，若是有，建立一個新的M，加入新P的本地隊列中，綁定其餘空閒的P。若是沒有空閒的P，那麼將G加入全局隊列中。每次執行時，循環執行本地隊列任務（本地隊列和全局隊列會交換任務），而後執行全局任務，都沒有的話，去其餘P裏面偷，偷一半。

以銀行辦理業務爲例，客戶表明G，窗口表明P，M表明排隊通道。sched表明一個全局的排隊通道。來了一個客戶，將安排到一個空閒的排隊通道M裏，這個排隊通道M綁定一個窗口P（每一個排隊通道都要綁定一個窗口P，一個窗口P能夠有多個排隊通道M，N:M）。若是來新客戶，看下有沒有空閒的窗口P，有的話，開一個新的排隊通道M，將新客戶安排到這個排隊通道里。若是沒有空閒的窗口P，此時，每一個排隊通道M都有客戶G，若是排隊通道M沒有滿，那麼G安排到一個有空閒位置的M。若是全部的M都滿了，那麼安排客戶G到全局排隊通道sched。執行過程當中，若是某個客戶的任務執行過久，（使用任務計數schedtick判斷），將客戶安排到排隊通道M末尾。（從新排隊）。若是某個窗口P對應的排隊通道M都空了（一個窗口P可能有多個排隊通道M），那麼看下全局排隊通道有沒有客戶G，有就過來（M的本地任務和sched全局任務有按期的交換策略），沒有的話，去其餘窗口P裏面偷一半客戶G過來執行。

不知道上面的例子描述的恰當不恰當，若是有錯誤歡迎指出。