協程的實現原理

咱們都知道Go語言是原生支持語言級併發的，這個併發的最小邏輯單元就是goroutine。goroutine就是Go語言提供的一種用戶態線程，固然這種用戶態線程是跑在內核級線程之上的。當咱們建立了不少的goroutine，而且它們都是跑在同一個內核線程之上的時候，就須要一個調度器來維護這些goroutine，確保全部的goroutine都使用cpu，而且是儘量公平的使用cpu資源。

這個調度器的原理以及實現值得咱們去深刻研究一下。支撐整個調度器的主要有4個重要結構，分別是M、G、P、Sched，前三個定義在runtime.h中，Sched定義在proc.c中。

• Sched結構就是調度器，它維護有存儲M和G的隊列以及調度器的一些狀態信息等。
• M表明內核級線程，一個M就是一個線程，goroutine就是跑在M之上的；M是一個很大的結構，裏面維護小對象內存cache（mcache）、當前執行的goroutine、隨機數發生器等等很是多的信息。
• P全稱是Processor，處理器，它的主要用途就是用來執行goroutine的，因此它也維護了一個goroutine隊列，裏面存儲了全部須要它來執行的goroutine，這個P的角色可能有一點讓人迷惑，一開始容易和M衝突，後面重點聊一下它們的關係。
• G就是goroutine實現的核心結構了，G維護了goroutine須要的棧、程序計數器以及它所在的M等信息。

理解M、P、G三者的關係對理解整個調度器很是重要，我從網絡上找了一個圖來講明其三者關係：

地鼠(gopher)用小車運着一堆待加工的磚。M就能夠看做圖中的地鼠，P就是小車，G就是小車裏裝的磚。一圖勝千言啊，弄清楚了它們三者的關係，下面咱們就開始重點聊地鼠是如何在搬運磚塊的。

#####啓動過程

在關心絕大多數程序的內部原理的時候，咱們都試圖去弄明白其啓動初始化過程，弄明白這個過程對後續的深刻分析相當重要。在asm_amd64.s文件中的彙編代碼_rt0_amd64就是整個啓動過程，核心過程以下：

CALL	runtime·args(SB)
CALL	runtime·osinit(SB)
CALL	runtime·hashinit(SB)
CALL	runtime·schedinit(SB)

// create a new goroutine to start program
PUSHQ	$runtime·main·f(SB)		// entry
PUSHQ	$0			// arg size
CALL	runtime·newproc(SB)
POPQ	AX
POPQ	AX

// start this M
CALL	runtime·mstart(SB)

啓動過程作了調度器初始化runtime·schedinit後，調用runtime·newproc建立出第一個goroutine，這個goroutine將執行的函數是runtime·main，這第一個goroutine也就是所謂的主goroutine。咱們寫的最簡單的Go程序」hello，world」就是徹底跑在這個goroutine裏，固然任何一個Go程序的入口都是從這個goroutine開始的。最後調用的runtime·mstart就是真正的執行上一步建立的主goroutine。

啓動過程當中的調度器初始化runtime·schedinit函數主要根據用戶設置的GOMAXPROCS值來建立一批小車(P)，無論GOMAXPROCS設置爲多大，最多也只能建立256個小車(P)。這些小車(p)初始建立好後都是閒置狀態，也就是還沒開始使用，因此它們都放置在調度器結構(Sched)的pidle字段維護的鏈表中存儲起來了，以備後續之需。

查看runtime·main函數能夠了解到主goroutine開始執行後，作的第一件事情是建立了一個新的內核線程(地鼠M)，不過這個線程是一個特殊線程，它在整個運行期專門負責作特定的事情——系統監控(sysmon)。接下來就是進入Go程序的main函數開始Go程序的執行。

至此，Go程序就被啓動起來開始運行了。一個真正幹活的Go程序，必定建立有很多的goroutine，因此在Go程序開始運行後，就會向調度器添加goroutine，調度器就要負責維護好這些goroutine的正常執行。

#####建立goroutine(G)

在Go程序中，時常會有相似代碼：

go do_something()

go關鍵字就是用來建立一個goroutine的，後面的函數就是這個goroutine須要執行的代碼邏輯。go關鍵字對應到調度器的接口就是runtime·newproc。runtime·newproc乾的事情很簡單，就負責製造一塊磚(G)，而後將這塊磚(G)放入當前這個地鼠(M)的小車(P)中。

每一個新的goroutine都須要有一個本身的棧，G結構的sched字段維護了棧地址以及程序計數器等信息，這是最基本的調度信息，也就是說這個goroutine放棄cpu的時候須要保存這些信息，待下次從新得到cpu的時候，須要將這些信息裝載到對應的cpu寄存器中。

假設這個時候已經建立了大量的goroutne，就輪到調度器去維護這些goroutine了。

#####建立內核線程(M)

Go程序中沒有語言級的關鍵字讓你去建立一個內核線程，你只能建立goroutine，內核線程只能由runtime根據實際狀況去建立。runtime何時建立線程？以地鼠運磚圖來說，磚(G)太多了，地鼠(M)又太少了，實在忙不過來，恰好還有空閒的小車(P)沒有使用，那就從別處再借些地鼠(M)過來直到把小車(p)用完爲止。這裏有一個地鼠(M)不夠用，從別處借地鼠(M)的過程，這個過程就是建立一個內核線程(M)。建立M的接口函數是:

void newm(void (*fn)(void), P *p)

newm函數的核心行爲就是調用clone系統調用建立一個內核線程，每一個內核線程的開始執行位置都是runtime·mstart函數。參數p就是一輛空閒的小車(p)。

每一個建立好的內核線程都從runtime·mstart函數開始執行了，它們將用分配給本身小車去搬磚了。

#####調度核心

newm接口只是給新建立的M分配了一個空閒的P，也就是至關於告訴借來的地鼠(M)——「接下來的日子，你將使用1號小車搬磚，記住是1號小車；待會本身到停車場拿車。」，地鼠(M)去拿小車(P)這個過程就是acquirep。runtime·mstart在進入schedule以前會給當前M裝配上P，runtime·mstart函數中的代碼：

} else if(m != &runtime·m0) {
	acquirep(m->nextp);
	m->nextp = nil;
}
schedule();

if分支的內容就是爲當前M裝配上P，nextp就是newm分配的空閒小車(P)，只是到這個時候才真正拿到手罷了。沒有P，M是沒法執行goroutine的，就像地鼠沒有小車沒法運磚同樣的道理。對應acquirep的動做是releasep，把M裝配的P給載掉；活幹完了，地鼠須要休息了，就把小車還到停車場，而後睡覺去。

地鼠(M)拿到屬於本身的小車(P)後，就進入工場開始幹活了，也就是上面的schedule調用。簡化schedule的代碼以下：

static void
schedule(void)
{
	G *gp;

	gp = runqget(m->p);
	if(gp == nil)
		gp = findrunnable();

	if (m->p->runqhead != m->p->runqtail &&
		runtime·atomicload(&runtime·sched.nmspinning) == 0 &&
		runtime·atomicload(&runtime·sched.npidle) > 0)  // TODO: fast atomic
		wakep();

	execute(gp);
}

schedule函數被我簡化了太多，主要是我不喜歡貼大段大段的代碼，所以只保留主幹代碼了。這裏涉及到4大步邏輯：

1. runqget, 地鼠(M)試圖從本身的小車(P)取出一塊磚(G)，固然結果可能失敗，也就是這個地鼠的小車已經空了，沒有磚了。
2. findrunnable, 若是地鼠本身的小車中沒有磚，那也不能閒着不幹活是吧，因此地鼠就會試圖跑去工場倉庫取一塊磚來處理；工場倉庫也可能沒磚啊，出現這種狀況的時候，這個地鼠也沒有偷懶停下幹活，而是悄悄跑出去，隨機盯上一個小夥伴(地鼠)，而後從它的車裏試圖偷一半磚到本身車裏。若是屢次嘗試偷磚都失敗了，那說明實在沒有磚可搬了，這個時候地鼠就會把小車還回停車場，而後睡覺休息了。若是地鼠睡覺了，下面的過程固然都中止了，地鼠睡覺也就是線程sleep了。
3. wakep, 到這個過程的時候，可憐的地鼠發現本身小車裏有好多磚啊，本身根本處理不過來；再回頭一看停車場竟然有閒置的小車，立馬跑到宿舍一看，你妹，竟然還有小夥伴在睡覺，直接給屁股一腳，「你妹，竟然還在睡覺，老子都快累死了，趕忙起來幹活，分擔點工做。」，小夥伴醒了，拿上本身的小車，乖乖幹活去了。有時候，可憐的地鼠跑到宿舍卻發現沒有在睡覺的小夥伴，因而會很失望，最後只好向工場老闆說——」停車場還有閒置的車啊，我快乾不動了，趕忙從別的工場借個地鼠來幫忙吧。」，最後工場老闆就搞來一個新的地鼠幹活了。
4. execute，地鼠拿着磚放入火種歡快的燒練起來。

注： 「地鼠偷磚」叫work stealing，一種調度算法。

到這裏，貌似整個工場都正常的運轉起來了，無懈可擊的樣子。不對，還有一個疑點沒解決啊，假設地鼠的車裏有不少磚，它把一塊磚放入火爐中後，什麼時候把它取出來，放入第二塊磚呢？難道要一直把第一塊磚燒練好，才取出來嗎？那估計後面的磚真的是等得花兒都要謝了。這裏就是要真正解決goroutine的調度，上下文切換問題。

#####調度點 當咱們翻看channel的實現代碼能夠發現，對channel讀寫操做的時候會觸發調用runtime·park函數。goroutine調用park後，這個goroutine就會被設置位waiting狀態，放棄cpu。被park的goroutine處於waiting狀態，而且這個goroutine不在小車(P)中，若是不對其調用runtime·ready，它是永遠不會再被執行的。除了channel操做外，定時器中，網絡poll等都有可能park goroutine。

除了park能夠放棄cpu外，調用runtime·gosched函數也可讓當前goroutine放棄cpu，但和park徹底不一樣；gosched是將goroutine設置爲runnable狀態，而後放入到調度器全局等待隊列（也就是上面提到的工場倉庫，這下就明白爲什麼工場倉庫會有磚塊(G)了吧）。

除此以外，就輪到系統調用了，有些系統調用也會觸發從新調度。Go語言徹底是本身封裝的系統調用，因此在封裝系統調用的時候，能夠作很多手腳，也就是進入系統調用的時候執行entersyscall，退出後又執行exitsyscall函數。 也只有封裝了entersyscall的系統調用纔有可能觸發從新調度，它將改變小車(P)的狀態爲syscall。還記一開始提到的sysmon線程嗎？這個系統監控線程會掃描全部的小車(P)，發現一個小車(P)處於了syscall的狀態，就知道這個小車(P)遇到了goroutine在作系統調用，因而系統監控線程就會建立一個新的地鼠(M)去把這個處於syscall的小車給搶過來，開始幹活，這樣這個小車中的全部磚塊(G)就能夠繞過以前系統調用的等待了。被搶走小車的地鼠等系統調用返回後，發現本身的車沒，不能繼續幹活了，因而只能把執行系統調用的goroutine放回到工場倉庫，本身睡覺去了。

從goroutine的調度點能夠看出，調度器仍是挺粗暴的，調度粒度有點過大，公平性也沒有想一想的那麼好。總之，這個調度器仍是比較簡單的。

#####現場處理 goroutine在cpu上換入換出，不斷上下文切換的時候，必需要保證的事情就是保存現場和恢復現場，保存現場就是在goroutine放棄cpu的時候，將相關寄存器的值給保存到內存中；恢復現場就是在goroutine從新得到cpu的時候，須要從內存把以前的寄存器信息所有放回到相應寄存器中去。

goroutine在主動放棄cpu的時候(park/gosched)，都會涉及到調用runtime·mcall函數，此函數也是彙編實現，主要將goroutine的棧地址和程序計數器保存到G結構的sched字段中，mcall就完成了現場保存。恢復現場的函數是runtime·gogocall，這個函數主要在execute中調用，就是在執行goroutine前，須要從新裝載相應的寄存器。