Golang - 調度剖析【第二部分】

回顧本系列的 第一部分，重點講述了操做系統調度器的各個方面，這些知識對於理解和分析 Go 調度器的語義是很是重要的。
在本文中，我將從語義層面解析 Go 調度器是如何工做的，並重點介紹其高級特性。
Go 調度器是一個很是複雜的系統，咱們不會過度關注一些細節，而是側重於剖析它的設計模型和工做方式。
咱們經過學習它的優勢以便夠作出更好的工程決策。

開始

當 Go 程序啓動時，它會爲主機上標識的每一個虛擬核心提供一個邏輯處理器（P）。若是處理器每一個物理核心能夠提供多個硬件線程（超線程），那麼每一個硬件線程都將做爲虛擬核心呈現給 Go 程序。爲了更好地理解這一點，下面實驗都基於以下配置的 MacBook Pro 的系統。

能夠看到它是一個 4 核 8 線程的處理器。這將告訴 Go 程序有 8 個虛擬核心可用於並行執行系統線程。

用下面的程序來驗證一下:

package main

import (
    "fmt"
    "runtime"
)

func main() {

    // NumCPU 返回當前可用的邏輯處理核心的數量
    fmt.Println(runtime.NumCPU())
}

當我運行該程序時，NumCPU() 函數調用的結果將是 8 。意味着在個人機器上運行的任何 Go 程序都將被賦予 8 個 P。

每一個 P 都被分配一個系統線程 M 。M 表明機器（machine），它仍然是由操做系統管理的，操做系統負責將線程放在一個核心上執行。這意味着當在個人機器上運行 Go 程序時，有 8 個線程能夠執行個人工做，每一個線程單獨鏈接到一個 P。

每一個 Go 程序都有一個初始 G。G 表明 Go 協程（Goroutine），它是 Go 程序的執行路徑。Goroutine 本質上是一個 Coroutine，但由於是 Go 語言，因此把字母 「C」 換成了 「G」，咱們獲得了這個詞。你能夠將 Goroutines 看做是應用程序級別的線程，它在許多方面與系統線程都類似。正如系統線程在物理核心上進行上下文切換同樣，Goroutines 在 M 上進行上下文切換。

最後一個重點是運行隊列。Go 調度器中有兩個不一樣的運行隊列：全局運行隊列(GRQ)和本地運行隊列(LRQ)。每一個 P 都有一個LRQ，用於管理分配給在P的上下文中執行的 Goroutines，這些 Goroutine 輪流被和P綁定的M進行上下文切換。GRQ 適用於還沒有分配給P的 Goroutines。其中有一個過程是將 Goroutines 從 GRQ 轉移到 LRQ，咱們將在稍後討論。

下面圖示展現了它們之間的關係：

協做式調度器

正如咱們在第一篇文章中所討論的，OS 調度器是一個搶佔式調度器。從本質上看，這意味着你沒法預測調度程序在任何給定時間將執行的操做。由內核作決定，一切都是不肯定的。在操做系統之上運行的應用程序沒法經過調度控制內核內部發生的事情，除非它們利用像 atomic 指令 和 mutex 調用之類的同步原語。

Go 調度器是 Go 運行時的一部分，Go 運行時內置在應用程序中。這意味着 Go 調度器在內核之上的用戶空間中運行。Go 調度器的當前實現不是搶佔式調度器，而是協做式調度器。做爲一個協做的調度器，意味着調度器須要明肯定義用戶空間事件，這些事件發生在代碼中的安全點，以作出調度決策。

Go 協做式調度器的優勢在於它看起來和感受上都是搶佔式的。你沒法預測 Go 調度器將會執行的操做。這是由於這個協做調度器的決策不掌握在開發人員手中，而是在 Go 運行時。將 Go 調度器視爲搶佔式調度器是很是重要的，而且因爲調度程序是非肯定性的，所以這並非一件容易的事。

Goroutine 狀態

就像線程同樣，Goroutines 有相同的三個高級狀態。它們標識了 Go 調度器在任何給定的 Goroutine 中所起的做用。Goroutine 能夠處於三種狀態之一：Waiting（等待狀態）、Runnable（可運行狀態）或Executing（運行中狀態）。

Waiting：這意味着 Goroutine 已中止並等待一些事情以繼續。這多是由於等待操做系統（系統調用）或同步調用（原子和互斥操做）等緣由。這些類型的延遲是性能降低的根本緣由。

Runnable ：這意味着 Goroutine 須要M上的時間片，來執行它的指令。若是同一時間有不少 Goroutines 在競爭時間片，它們都必須等待更長時間才能獲得時間片，並且每一個 Goroutine 得到的時間片都縮短了。這種類型的調度延遲也可能致使性能降低。

Executing ：這意味着 Goroutine 已經被放置在M上而且正在執行它的指令。與應用程序相關的工做正在完成。這是每一個人都想要的。

上下文切換

Go 調度器須要有明肯定義的用戶空間事件，這些事件發生在要切換上下文的代碼中的安全點上。這些事件和安全點在函數調用中表現出來。函數調用對於 Go 調度器的運行情況是相當重要的。如今（使用 Go 1.11或更低版本），若是你運行任何未進行函數調用的緊湊循環，你會致使調度器和垃圾回收有延遲。讓函數調用在合理的時間範圍內發生是相當重要的。

注意：在 Go 1.12 版本中有一個提議被接受了，它可使 Go 調度器使用非協做搶佔技術，以容許搶佔緊密循環。

在 Go 程序中有四類事件，它們容許調度器作出調度決策：

• 使用關鍵字 go
• 垃圾回收
• 系統調用
• 同步和編配

使用關鍵字 go

關鍵字 go 是用來建立 Goroutines 的。一旦建立了新的 Goroutine，它就爲調度器作出調度決策提供了機會。

垃圾回收

因爲 GC 使用本身的 Goroutine 運行，因此這些 Goroutine 須要在 M 上運行的時間片。這會致使 GC 產生大量的調度混亂。可是，調度程序很是聰明地瞭解 Goroutine 正在作什麼，它將智能地作出一些決策。

系統調用

若是 Goroutine 進行系統調用，那麼會致使這個 Goroutine 阻塞當前M，有時調度器可以將 Goroutine 從M換出並將新的 Goroutine 換入。然而，有時須要新的M繼續執行在P中排隊的 Goroutines。這是如何工做的將在下一節中更詳細地解釋。

同步和編配

若是原子、互斥量或通道操做調用將致使 Goroutine 阻塞，調度器能夠將之切換到一個新的 Goroutine 去運行。一旦 Goroutine 能夠再次運行，它就能夠從新排隊，並最終在M上切換回來。

異步系統調用

當你的操做系統可以異步處理系統調用時，可使用稱爲網絡輪詢器的東西來更有效地處理系統調用。這是經過在這些操做系統中使用 kqueue（MacOS），epoll（Linux）或 iocp（Windows）來實現的。

基於網絡的系統調用能夠由咱們今天使用的許多操做系統異步處理。這就是爲何我管它叫網絡輪詢器，由於它的主要用途是處理網絡操做。經過使用網絡輪詢器進行網絡系統調用，調度器能夠防止 Goroutine 在進行這些系統調用時阻塞M。這可讓M執行P的 LRQ 中其餘的 Goroutines，而不須要建立新的M。有助於減小操做系統上的調度負載。

下圖展現它的工做原理：G1正在M上執行，還有 3 個 Goroutine 在 LRQ 上等待執行。網絡輪詢器空閒着，什麼都沒幹。

接下來，狀況發生了變化：G1想要進行網絡系統調用，所以它被移動到網絡輪詢器而且處理異步網絡系統調用。而後，M能夠從 LRQ 執行另外的 Goroutine。此時，G2就被上下文切換到M上了。

最後：異步網絡系統調用由網絡輪詢器完成，G1被移回到P的 LRQ 中。一旦G1能夠在M上進行上下文切換，它負責的 Go 相關代碼就能夠再次執行。這裏的最大優點是，執行網絡系統調用不須要額外的M。網絡輪詢器使用系統線程，它時刻處理一個有效的事件循環。

同步系統調用

若是 Goroutine 要執行同步的系統調用，會發生什麼？在這種狀況下，網絡輪詢器沒法使用，而進行系統調用的 Goroutine 將阻塞當前M。這是不幸的，可是沒有辦法防止這種狀況發生。須要同步進行的系統調用的一個例子是基於文件的系統調用。若是你正在使用 CGO，則可能還有其餘狀況，調用 C 函數也會阻塞M。

注意：Windows 操做系統確實可以異步進行基於文件的系統調用。從技術上講，在 Windows 上運行時，可使用網絡輪詢器。

讓咱們來看看同步系統調用（如文件I/O）會致使M阻塞的狀況：G1將進行同步系統調用以阻塞M1。

調度器介入後：識別出G1已致使M1阻塞，此時，調度器將M1與P分離，同時也將G1帶走。而後調度器引入新的M2來服務P。此時，能夠從 LRQ 中選擇G2並在M2上進行上下文切換。

阻塞的系統調用完成後：G1能夠移回 LRQ 並再次由P執行。若是這種狀況須要再次發生，M1將被放在旁邊以備未來使用。

任務竊取（負載均衡思想）

調度器的另外一個方面是它是一個任務竊取的調度器。這有助於在一些領域保持高效率的調度。首先，你最不但願的事情是M進入等待狀態，由於一旦發生這種狀況，操做系統就會將M從內核切換出去。這意味着P沒法完成任何工做，即便有 Goroutine 處於可運行狀態也不行，直到一個M被上下文切換回核心。任務竊取還有助於平衡全部P的 Goroutines 數量，這樣工做就能更好地分配和更有效地完成。

看下面的一個例子：這是一個多線程的 Go 程序，其中有兩個P，每一個P都服務着四個 Goroutine，另在 GRQ 中還有一個單獨的 Goroutine。若是其中一個P的全部 Goroutines 很快就執行完了會發生什麼？

如你所見：P1的 Goroutines 都執行完了。可是還有 Goroutines 處於可運行狀態，在 GRQ 中有，在P2的 LRQ 中也有。
這時P1就須要竊取任務。

竊取的規則在這裏定義了：https://golang.org/src/runtim...

if gp == nil {
        // 1/61的機率檢查一下全局可運行隊列，以確保公平。不然，兩個 goroutine 就能夠經過不斷地相互替換來徹底佔據本地運行隊列。
        if _g_.m.p.ptr().schedtick%61 == 0 && sched.runqsize > 0 {
            lock(&sched.lock)
            gp = globrunqget(_g_.m.p.ptr(), 1)
            unlock(&sched.lock)
        }
    }
    if gp == nil {
        gp, inheritTime = runqget(_g_.m.p.ptr())
        if gp != nil && _g_.m.spinning {
            throw("schedule: spinning with local work")
        }
    }
    if gp == nil {
        gp, inheritTime = findrunnable()
    }

根據規則，P1將竊取P2中一半的 Goroutines，竊取完成後的樣子以下：

咱們再來看一種狀況，若是P2完成了對全部 Goroutine 的服務，而P1的 LRQ 也什麼都沒有，會發生什麼?

P2完成了全部任務，如今須要竊取一些。首先，它將查看P1的 LRQ，但找不到任何 Goroutines。接下來，它將查看 GRQ。
在那裏它會找到G9，P2從 GRQ 手中搶走了G9並開始執行。以上任務竊取的好處在於它使M不會閒着。在竊取任務時，M是自旋的。這種自旋還有其餘的好處，能夠參考 work-stealing 。

實例

有了相應的機制和語義，我將向你展現如何將全部這些結合在一塊兒，以便 Go 調度程序可以執行更多的工做。設想一個用 C 編寫的多線程應用程序，其中程序管理兩個操做系統線程，這兩個線程相互傳遞消息。

下面有兩個線程，線程 T1 在內核 C1 上進行上下文切換，而且正在運行中，這容許 T1 將其消息發送到 T2。

當 T1 發送完消息，它須要等待響應。這將致使 T1 從 C1 上下文換出並進入等待狀態。
當 T2 收到有關該消息的通知，它就會進入可運行狀態。
如今操做系統能夠執行上下文切換並讓 T2 在一個核心上執行，而這個核心剛好是 C2。接下來，T2 處理消息並將新消息發送回 T1。

而後，T2 的消息被 T1 接收，線程上下文切換再次發生。如今，T2 從運行中狀態切換到等待狀態，T1 從等待狀態切換到可運行狀態，再被執行變爲運行中狀態，這容許它處理併發回新消息。

全部這些上下文切換和狀態更改都須要時間來執行，這限制了工做的完成速度。
因爲每一個上下文切換可能會產生 50 納秒的延遲，而且理想狀況下硬件每納秒執行 12 條指令，所以你會看到有差很少 600 條指令，在上下文切換期間被停滯掉了。而且因爲這些線程也在不一樣的內核之間跳躍，因 cache-line 未命中引發額外延遲的可能性也很高。

下面咱們還用這個例子，來看看 Goroutine 和 Go 調度器是怎麼工做的：
有兩個goroutine，它們彼此協調，來回傳遞消息。G1在M1上進行上下文切換，而M1剛好運行在C1上，這容許G1執行它的工做。即向G2發送消息。

G1發送完消息後，須要等待響應。M1就會把G1換出並使之進入等待狀態。一旦G2獲得消息，它就進入可運行狀態。如今 Go 調度器能夠執行上下文切換，讓G2在M1上執行，M1仍然在C1上運行。接下來，G2處理消息並將新消息發送回G1。

當G2發送的消息被G1接收時，上下文切換再次發生。如今G2從運行中狀態切換到等待狀態，G1從等待狀態切換到可運行狀態，最後返回到執行狀態，這容許它處理和發送一個新的消息。

表面上看起來沒有什麼不一樣。不管使用線程仍是 Goroutine，都會發生相同的上下文切換和狀態變動。然而，使用線程和 Goroutine 之間有一個主要區別：
在使用 Goroutine 的狀況下，會複用同一個系統線程和核心。這意味着，從操做系統的角度來看，操做系統線程永遠不會進入等待狀態。所以，在使用系統線程時的開銷在使用 Goroutine 時就不存在了。

基本上，Go 已經在操做系統級別將 IO-Bound 類型的工做轉換爲 CPU-Bound 類型。因爲全部的上下文切換都是在應用程序級別進行的，因此在使用線程時，每一個上下文切換(平均)不至於遲滯 600 條指令。該調度程序還有助於提升 cache-line 效率和 NUMA。在 Go 中，隨着時間的推移，能夠完成更多的工做，由於 Go 調度器嘗試使用更少的線程，在每一個線程上作更多的工做，這有助於減小操做系統和硬件的負載。

結論

Go 調度器在設計中考慮到複雜的操做系統和硬件的工做方式，真是使人驚歎。在操做系統級別將 IO-Bound 類型的工做轉換爲 CPU-Bound 類型的能力是咱們在利用更多 CPU 的過程當中得到巨大成功的地方。這就是爲何不須要比虛擬核心更多的操做系統線程的緣由。你能夠合理地指望每一個虛擬內核只有一個系統線程來完成全部工做(CPU和IO)。對於網絡應用程序和其餘不會阻塞操做系統線程的系統調用的應用程序來講，這樣作是可能的。

做爲一個開發人員，你固然須要知道程序在運行中作了什麼。你不可能建立無限數量的 Goroutine ，並期待驚人的性能。越少越好，可是經過了解這些 Go 調度器的語義，您能夠作出更好的工程決策。

在下一篇文章中，我將探討以保守的方式利用併發性以得到更好的性能，同時平衡可能須要增長到代碼中的複雜性。