[翻譯]Go語言調度器

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Go語言調度器

譯序

本文翻譯 Daniel Morsing 的博文 The Go scheduler。個人認為這篇文章把Go Routine和調度器的知識講的淺顯易懂。作為一篇介紹性的文章。非常不錯。

譯文

介紹

Go 1.1版本號碼最大的特性之中的一個就是一個新的調度器，由Dmitry Vyukov貢獻。

這個新的調度器為並行Go程式帶來了令人激動、無以後繼的效能提升。我認為我應該為之寫點什麼東西。

這篇部落格的大部分內容都已經在這篇原始設計文檔中描寫敘述過了，這是一份相當好理解的文章。可是略顯技術性。

儘管該設計文檔已經包括了關於新調度器你所須要知道的一切。但本篇博文包括圖片，所以非常明顯它略勝一籌。

為什麼Go執行時須要一個調度器

在我們研究這個新調度器之前，我們須要搞清楚為什麼須要它，為什麼要製造一個使用者空間的調度器。即使作業系統已經能為你調度線程。

POSIX線程API非常大程度上是現有UNIX進程模型的邏輯擴充，線程擁有很多與進程同樣的控制。線程有自己的訊號掩碼，能夠設定CPU親和力，能夠被分組到cgroups，也能夠查詢它們使用了哪些資源。

全部這些控制由於一些Go語言使用Goroutine時並不須要的特性而添加了開銷，而且當你的程式有10萬個線程時這些開銷就高速疊加起來。

還有一個問題是作業系統無法做出通知的調度決策，基於Go的模型。比方，Go的垃圾收集器須要在收集時全部線程都停止，而且記憶體須要處於一致的狀態。

這涉及到等待執行中的線程達到我們所知的記憶體一致的點。

當你有非常多線程須要隨機調度的時候，非常大的可能性你須要等待很多線程已達到一致的狀態。

Go的調度器能夠做出決策，僅僅在當他知道記憶體已經一致的時候進行調度。

這意味著當我們由於垃圾收集而停下來時，我們僅僅須要等待那些正在CPU核心中執行的線程。

我們的角色

線程通常有3種模型：一個是N:1模型，該模型中多個使用者線程執行在一個核心線程中。這樣的模型的好處在於環境切換非常快，可是無法充分利用多核線程。還有一個是1:1模型，當中一個執行線程相應一個系統線程。該模型充分利用機器上的多個核心，可是環境切換非常慢，由於須要陷入核心。

Go採用M:N的模型，嘗試取兩者的好處。它在隨意數量的系統線程上調度隨意數量的使用者線程，這樣你不僅能夠獲得非常快的環境切換，也能夠充分利用你系統的多核。這樣的方式的主要缺點是給調度器帶來的複雜性。

為了完畢調度的任務，Go調度器使用到了3個實體：

三角形表示系統線程，它由作業系統管理的，行為非常像POSIX線程。在執行時代碼中，它被稱為M（Machine，機器）。
圓圈表示一個goroutine。它包括了棧，指令指標，以及其它對調度goroutine非常重要的資訊，比如其堵塞的channel。在執行時代碼中。稱作G。
矩形表示調度的上下文。

你能夠把它看成是在單個線程中執行Go代碼的調度器的本地版本號碼。

它是讓我們從N:1調度到M:N調度的重要部分。在執行時代碼中。稱作P（Processor，處理器）。

圖中我們看到有2個線程（M），每一個線程都持有一個上下文（P）。每一個上下文都執行著一個goroutine（G）。為了執行goroutines，每一個線程都必須持有一個上下文。

內容相關的數量是在啟動時被設定為環境變數GOMAXPROCS的值，或者通過執行時調用函數GOMAXPROCS()進行設定。

一般來說，這個值在程式執行過程中不會改變。上下文數量固定意味著隨意時刻僅僅有GOMAXPROCS個線程在執行go代碼。

我們能夠利用這一點依據不同機器調節go進程的調用。比如在4核的CPU上用4個線程執行go代碼。

灰色的goroutine是沒在執行中的，但等待著被調度。它們被安排在一個稱為runqueues的列表中。當一個goroutine執行go運算式時，goroutines被加入到列表的末尾。當一個上下文執行goroutine到調度點時，它從它的runqueues中彈出一個goroutine。設定棧和指令指標，然後開始執行這個goroutine。

為了打破相互排斥，每一個上下文有自己的本地runqueues。

前一個版本號碼的go調度器僅僅有一個全域的runqueues以及一個相互排斥鎖來保護它。線程常常被堵塞，等待相互排斥鎖釋放接觸堵塞。假設你的機器有32個核心，這將變得非常低效。

僅僅要全部上下文都有goroutine能夠執行，go的調度器就會依照這樣的穩定的狀態進行調度。

然而，存在幾種例外的情況。

你要（系統）調用誰？

如今你可能會好奇，究竟為什麼要上下文？難道我們不能拋棄上下文，直接把runqueues放線上程上嗎？不盡然。我們之所以須要上下文，是由於我們能夠在當前執行中的線程須要堵塞時把上下文交給其它線程。
須要堵塞的一個範例是我們進行系統調用。由於線程不能既執行代碼又堵塞於系統調用，我們須要交接上下文。以繼續進行調度。

我們能夠看到。一個線程放棄了它的上下文，好讓其它線程能夠執行之。調度器保證有足夠的線程來執行全部上下文。插圖中的M1可能剛剛被建立，用於處理這個系統調用。或者它來自於線程緩衝。

執行系統調用的線程會繼續持有產生系統調用的goroutine。由於從技術上講它扔在執行，僅僅是堵塞在作業系統中了。

當系統調用返回時。線程必須嘗試獲得上下文。才得以繼續執行返回的goroutine。通常的操作模式從其它線程那偷取一個上下文。

假設偷取失敗，它會把goroutine放到全域的runqueue，將自己進入線程緩衝然後睡眠。

當內容相關的本地runqueue為空白時，就會到全域的runqueue去拉取。上下文也會定期檢查全域runqueue，否則全域runqueue中的goroutine可能永遠都不能執行終於餓死。

偷取工作

系統的穩定點改變的還有一種情況是噹噹中一個內容相關的runqueue為空白。沒有goroutine能夠調度。這在上下文之間的runqueues不平衡的情況下可能發生。

這可能導致上下文耗盡其runqueue而系統仍然有工作要完畢。

為了繼續執行go代碼，上下文能夠從全域runqueue中擷取goroutine，可是假設當中沒有goroutines，上下文就須要從別的地方擷取。

所謂別的地方即是其它的上下文。

當一個上下文耗完其goroutines時，它會從另外一個上下文偷取一半的goroutine。

這保證了每一個上下文總是有活兒能夠幹，從而保證了全部線程都以其最大的能力工作著。