goroutine的調度

goroutine的調度

概述

Go 1.1 重要特性之一就是由 Dmitry Vyukov 貢獻的新調度器。無需對程序進行任何調整，新的調度器就能夠爲 Go 程序帶來使人興奮的性能提高。所以我以爲有必要就此寫點什麼。

在本博文所述的大多數內容都已經在原始的設計文檔中有所介紹。那是一篇至關全面的文檔，同時也至關專業。

你想要了解的關於新的調度器的一切都能在那篇文檔裏找到，而這篇博文描繪了總體狀況，因此優略得所。

爲何 Go 運行時須要一個調度器

在瞭解新調度器以前，先要了解爲何須要它。爲何在操做系統已經可以對線程進行調度的狀況下還須要建立一個用戶空間調度器。

POSIX 線程 API 絕對是對已有的 Unix 進程模型的邏輯擴展，這樣線程就得到了跟進程相似的控制方式。線程擁有本身的信號掩碼，能夠與 CPU 關聯起來，能夠放入 cgroups 或查詢哪些資源被其使用。全部這些控制方式所帶來的特性對於使用 goroutine 的 Go 程序來講都不須要，而且當程序有 100000 個線程的時候，所需的控制會急速膨脹。

另外一個問題是 OS 不能基於 Go 模型根據實際狀況進行調度。例如，Go 垃圾收集器在執行回收時，須要全部的線程都先中止，而內存也必須在一致的狀態。這包含了等待正在運行的線程執行到某個已知內存會達到一致狀態的地方。

當有許多線程進行隨機的調度，挑戰是你必須不停的等待他們達到一致狀態。 Go 調度器能夠決定在已知內存會一致的地方進行調度。這意味着當停下進行垃圾收集時，只須要等待在 CPU 內核上實際運行的線程。

咱們的陣容

一般有三個線程模型。一個是 N:1，也就是若干個用戶空間線程運行在一個 OS 線程上。它的好處是上下文切換很是迅速，而壞處是沒法發揮多核系統。另外一個是 1:1，也就是一個執行線程對應一個 OS 線程。好處是能夠利用機器上的全部內核，不過因爲它是經過 OS 來進行的，因此上下文切換很是慢。

Go 試圖利用 M:N 調度器在兩個世界中找到平衡點。若干 goroutine 調度在若干 OS 線程上。獲得了快速的上下文切換，而且能夠利用系統裏的全部核心。而主要的問題是這個方法會增長調度器的複雜度。

爲了完成任務的調度，Go 調度器使用了 3 個主要的實體：

三角形表明 OS 線程。它是由系統管理執行的線程，而且工做方式與標準的 POSIX 線程至關相似。在運行時的代碼裏，叫作 M 表明設備。

圓形表明 goroutine。它包括了棧、指令指針和其餘調度 goroutine 所需的重要信息，如可能阻塞它的任何一個 channel。在運行時代碼裏，它被叫作 G。

矩形表明調度的上下文。能夠將其看做是一個在一個線程上運行 Go 代碼的局部版本的調度器。這是從 N:1 調度器演化到 M:N 調度器的重要的一環。在運行時代碼中，它被叫作 P 表明處理器。關於這部分還得再多說幾句。

這裏有 2 個線程（M），每一個都擁有一個上下文（P），每一個都執行一個 goroutine（G）。線程必須擁有一個上下文才能執行 goroutine。

**上下文的數量是由環境變量 GOMAXPROCS 在啓動的時候設置的，也能夠經過運行時函數 GOMAXPROCS() 設置。事實上上下文的數量是固定的，這也就是說任什麼時候候都只有 GOMAXPROCS 個 Go 代碼在執行。**可使用這個來在不一樣的計算機上進行調整，好比 4 核 PC 會運行 4 條 Go 代碼的線程。

灰色的 goroutine 沒有在運行，可是已經準備好被調度了。它們排列在一個叫作 runqueues 的列表裏。當 goroutine 執行 go 語句時就會被添加到 runquque 的尾部。一個正在運行的 goroutine 到達調度點時，上下文就會從 runqueue 中彈出這個 goroutine，而且設置棧和指令指針，而後開始執行下一個 goroutine。

爲了減小互斥爭用，每一個上下文都有它本身本地的 runqueue。上一個版本的 Go 調度器只有一個使用互斥量保護的全局 runqueue。線程常常爲了等待互斥量解鎖而被阻塞。當在一個 32 核的機器上想要儘量的壓榨性能時這會變得很是糟糕。

只要上下文有 goroutine 須要運行，調度器就會在這個穩定的狀態下持續的進行調度。然而，有一些狀況可能會改變這個局面。

你要（系統）調用誰？

你如今可能在想，爲何須要上下文？爲何不能拋開上下文直接將 runqueue 放在線程上？其實不是這樣的。有上下文的緣由是當因爲某些緣由正在執行的線程會阻塞時能夠切換到其餘線程。

一個關於阻塞的例子就是系統調用。因爲線程沒法在運行代碼的同時又阻塞在系統調用上，因此須要上下文進行切換來保證調度。

這裏能夠看到一個線程放棄了它的上下文，所以其餘線程能夠運行。調度器保證了有足夠的線程運行全部的上下文。爲了正確的處理系統調用，會建立或者是從線程緩存中獲取上圖中的 M1。技術上說被系統調用線程持有的進行了系統調用的 goroutine 仍然是在運行的，儘管在 OS 層它被阻塞了。

當系統調用返回，線程必須嘗試獲取上下文以便讓 goroutine 繼續運行。一般的模式是從其餘線程竊取一個上下文。若是沒辦法偷獲得，就會將 goroutine 放入全局 runqueue 中，而後本身返回線程緩存繼續休眠。

當上下文執行完本地的 runqueue 後，會從全局 runqueue 獲取 goroutine。上下文也會按期的檢查全局 runqueue。不然的話在全局 runqueue 上的 goroutine 可能因爲缺少資源而永遠都不會運行。

這個處理系統調用的方法說明了爲何即便 GOMAXPROCS 爲 1 的時候，Go 程序也會運行多個線程。運行時用 goroutine 調用系統調用，而讓線程藏在背後。

竊取工做

當一個上下文調度執行完全部的 goroutine 時系統的穩定狀態也會發生變化。這發生在上下文的 runqueue 分配的工做不平衡的時候。這會致使當上下文清空其 runqueue 後，在系統中仍然有工做須要完成。爲了讓 Go 代碼繼續執行，上下文能夠從全局 runqueue 獲取 goroutine，可是若是沒有 goroutine 在其中的話，總得從其餘什麼地方獲取到它們。

這個其餘地方其實就是其餘上下文。當一個上下文執行完，它會試圖偷取其餘上下文的一半 runqueue。這保證了每一個上下文都老是有工做可作，也保證了全部的線程都進其最大的能力在工做。

何去何從？

還有許多調度器的細節，如 cgo 線程，LockOSThread() 函數和帶有網絡池的指令。它們不在本文討論的範圍內，可是仍然值得學習。之後我可能會寫一些關於這些的內容。在 Go 運行時庫中還有許許多多有趣的創造等待着被探索。