理解golang調度之二 ：Go調度器

前言

這一部分有三篇文章，主要是講解go調度器的一些內容

三篇文章分別是:

• 理解golang調度之一 ：操做系統調度
• 理解golang調度之二 ：Go調度器
• 理解golang調度之三：併發

簡介

第一篇文章解釋了關於操做系統層級的調度，我認爲這對於理解Go的調度是很重要的。這一部分我會在語義層級解釋Go調度器是如何工做的，而且着重關注它的一些高級行爲。Go 調度器是一個十分複雜的系統，細節不重要，重要的是對於其工做和行爲有一個好的理解,這會讓你作出更好的工程方面的決定。

從一個程序開始

當你的go程序啓動，主機上定義的每個虛擬內核都會爲它分配一個邏輯處理器(P)，若是你的處理器上每一個物理內核有多個硬件線程（超線程），每一個硬件線程對於你的go程序來講就是一個虛擬內核。爲了理解這個事情，看一下個人MacBook Pro的系統配置。

圖2.1

你能夠看到一個單獨處理器有4個物理核心。配置表沒有顯示每一個物理核心有多少個硬件線程。Intel Core i7 處理器有本身的超線程，也就是每一個物理內核上有兩個硬件線程。所以Go程序知道並行執行操做系統線程的時候，會有8個虛擬內核能夠用

爲了測試這個事情，看一下下面的程序

L1

package main

import (
	"fmt"
	"runtime"
)

func main() {

    // NumCPU returns the number of logical
    // CPUs usable by the current process.
    fmt.Println(runtime.NumCPU())
}
複製代碼

我在個人本機上運行這個程序，NumCPU()方法會返回8，我在本機上跑的任何Go程序會分配8個邏輯處理器(P)。

每一個P會分配一個OS線程（M）。M表明機器(machine)。這個線程是OS來處理的而且OS還負責把線程放置到一個core上去執行。這意味着當我跑一個Go程序在個人機器上，我有8個可用的線程去執行個人工做，每一個線程單獨連到一個P上。

每一個Go程序同時也會有一個初始的Goroutine（G）。一個Goroutine本質上是一個協程（Coroutine），可是在go裏，把字面「C」替換爲「G」因此咱們叫Goroutine。你能夠認爲Goroutine是一個用戶程序級別的線程並且它跟OS線程不少方面都相似。區別僅僅是OS線程在內核(Core)上進行上下文切換（換上和換下）,而Goroutines是在M上。

最後一個讓人困惑的就是運行隊列。在Go 調度器中有兩種不一樣的運行隊列：全局運行隊列（GRQ）和本地運行隊列(LRQ)。每一個P會分配一個LRQ去處理P的上下文要執行的Goroutines 。這些Goroutines會在綁定到P的M上進行上下文的切換。GRQ會處理尚未分配到P上的Goroutines 。Goroutines從GRQ挪到LRQ的過程一會咱們一下子會說。

圖2.2是包含了全部相關組件的一張圖片

圖2.2

協做調度

咱們在第一部分的內容講到了，OS調度器是一個搶佔式調度器。也就是說你不知道調度器下一步會執行什麼。內核所作的決定都是不肯定的。運行在OS頂層的應用程序沒法控制內核裏面的調度，除非你使用同步的原始操做，例如atomic指令和mutex調用

Go調度器是Go runtime的一部分，Go runtime會編譯到你應用程序裏。這意味着Go調度器運行在內核之上的用戶空間(user space)

當前Go調度器採用的不是搶佔式調度器，而是協做試調度器。協做試調度器，意味着調度器須要代碼中安全點處發生的定義好的用戶空間事件去作出調度決策。

Go的協做調度有一個很是棒的地方就是，它看上去像是搶佔式的。你沒辦法預測Go調度器將要作什麼，這是由於協做試調度器的決策不是開發人員而是go runtime去作的。將Go調度器看作是一個搶佔式調度器是很重要的，由於調度是不肯定的，這裏不須要再過多延伸。

Goroutine狀態

和線程同樣。Goroutine有三種相同的高級狀態。Goroutine能夠是任何一種狀態：等待（Waiting）、可執行（Runnable）、運行中（Executing）.

等待：此時Goroutine已經中止而且等待事件發生來去再次執行。這多是出於等待操做系統（系統調用）或同步調用（原子操做atomic和互斥操做mutex）等緣由。 這些類型的延遲是性能不佳的根本緣由。

可執行： 此時Goroutine想要在M上執行分配給它的指令。若是有不少Goroutines想要M上的時間片，那麼Goroutines必須等待更長時間。並且，隨着更多Goroutines爭奪時間片，單獨Goroutines分配的時間就會縮短，這種類型的調度延時也會致使性能不好。

運行中：這意味着Goroutines已經放置在M上而且執行它的指令。此時應用程序的工做即將完成，這是咱們想要的狀態。

上下文切換（Context Switching）

Go調度程序須要明肯定義的用戶空間事件，這些事件發生在代碼中的安全點以進行上下文切換。這些事件和安全點在函數調用時發生。函數調用對Go調度器的運行情況相當重要。Go 1.11 或者更低版本中，若是你跑一個不作函數調用的死循環，會致使調度器延時和垃圾回收延時。合理的時機使用函數調用十分重要。

注意：相關issue和建議已經被提出來，而且應用到了1.12版本中。應用非協做的搶佔式技術，使得在tight loop中進行搶佔。

Go程序中有4種類型的事件，容許調度器去作出調度決策。這不意味着某一個事件老是會發生，而是說調度器有機會去作出調度。

• 使用關鍵字 go
• 垃圾回收
• 系統調用
• 同步處理

使用關鍵字 go

使用關鍵字go來建立Goroutine。一旦一個新的Goroutine建立好，調度器便有機會去作出調度決定

垃圾回收

GC時候會有它本身的Goroutines，這些Goroutines也須要M上的時間片。這會致使GC產生不少調度混亂。可是調度器很聰明，它知道Goroutines在作什麼，而後會作出合理的調度決策。一個聰明的決定就是對那些想要觸及到堆的Goroutine和GC時候不會觸及堆的Goroutine進行上下文切換。GC發生的時候會產生不少調度決策。

系統調用

若是一個Goroutine作出了會致使M阻塞的系統調用，調度器有時候會用一個新的Goroutine從M上替換下這個Goroutine。可是有時候會須要一個新的M去執行掛在P隊列上的Goroutine，這種狀況我會在下一部分講解。

同步處理

若是atomic、mutex或者是channel操做的調用致使了Goroutine的阻塞，調度器會切換一個新的Goroutine去執行。一旦那個Goroutine又能夠從新執行了，他會被掛到隊列上並最終在M上會上下文切換回去。

異步系統調用

當OS有能力去處理異步的系統調用時候，使用網絡輪詢器(network poller)去處理系統調用會更加高效。不一樣的操做系統分別使用了kqueue (MacOS)、epoll (Linux) 、 iocp (Windows) 對此做了實現。

今天許多操做系統都能處理基於網絡(Networking-based)的系統調用。這也是網絡輪詢器(network poller)這一名字的由來，由於它的主要用途就是處理網絡操做。網絡系統上經過使用network poller，調度器能夠防止Goroutines在系統調用的時候阻塞M。這可讓M可以去執行其餘在P的 LRQ上面的其餘Goroutines而不是再去新建一個M。這能夠減小OS上的調度加載。

最好的方式就是給一個例子看看它是如何工做的。

圖2.3

圖2.3展現了基本的調用圖例。Goroutine-1正在M上面執行而且有3個Goroutine在LRQ上等待想要獲取M的時間片。network poller此時空閒沒事作。

圖2.4

圖2.4中 Goroutine-1想要進行network system調用，所以Goroutine-1移到了network poller上面而後處理異步調用，一旦Goroutine-1從M上移到network poller，M即可以去執行其餘LRQ上的Goroutine。此時 Goroutine-2切換到了M上面。

圖2.5

圖2.5中，network poller的異步網絡調用完成而且Goroutine-1回到了P的LRQ上面。一旦Goroutine-1可以切換回M上，Go的相關代碼便可以再次執行。很大好處是，在執行network system調用時候，咱們不須要其餘額外的M。network poller有一個OS線程可以有效的處理事件循環。

同步系統調用

當Goroutine想進行系統調用沒法異步進行該怎麼辦呢？這種狀況下，沒法使用 network poller而且Goroutine產生的系統調用會阻塞M。很不幸可是咱們沒法阻止這種狀況發生。一個例子就是基於文件的系統調用。若是你使用CGO，當你調用C函數的時候也會有其餘狀況發生會阻塞M。

注意：Windows操做系統確實有能力去異步進行基於文件的系統調用。從技術上講，在Windows上運行時可使用network poller。

咱們看一下同步系統調用(好比file I/O)阻塞M的時候會發生什麼。

圖2.6

圖2.6又一次展現了咱們的基本調度圖例。可是這一次Goroutine-1的同步系統調用會阻塞M1

圖2.7

圖2.7中，調度器可以肯定Goroutine-1已經阻塞了M。這時，調度器會從P上拿下來M1，Goroutine-1依舊在M1上。而後調度器會拿來一個新的M2去服務P。此時LRQ上的Goroutine-2會上下文切換到M2上。若是已經有一個可用的M了，那麼直接用它會比新建一個M要更快。

圖2.8

圖2.8中，Goroutine-1的阻塞系統調用結束了。此時Goroutine-1可以回到LRQ的後面而且可以從新被P執行。M1以後會被放置一邊供將來相似的狀況使用。

工做竊取（Work Stealing）

調度器的另外一個層面，它其實也是一個work-stealing的調度器。這在一些狀況下可以讓調度更有效率。你最不想看到的事情是一個M進入了等待狀態，由於這一旦發生，OS將會把M從core上切換下來。這意味着即便有可執行的Goroutine， P此時也無法幹活了，直到M從新切換回core上。Work stealing同時也會平衡P上的全部Goroutines從而可以使工做更好的分配，更有效率。

讓咱們看一個例子

圖2.9

圖2.9裏，咱們有個多線程的Go程序。兩個P分別服務4個Goroutines。而且一個單獨的Goroutine在GRQ上。那麼若是其中一個P很快執行完它全部的Goroutines會怎麼樣？

圖2.10

P1沒有更多Goroutine去執行了，可是在GRQ和P2的LRQ中都有可執行的Goroutines。這種狀況P1會去竊取工做，Work Stealing的規則以下

L2

runtime.schedule() {
    // only 1/61 of the time, check the global runnable queue for a G.
    // if not found, check the local queue.
    // if not found,
    //     try to steal from other Ps.
    //     if not, check the global runnable queue.
    //     if not found, poll network.
}
複製代碼

因此基於L2的規則，P1須要去看P2的LRQ上的Goroutines而且拿走一半。

圖2.11

圖2.11中，一半的Goroutines從P2上偷走，P1如今能夠執行那些Goroutines

若是P2完成了全部Goroutines的執行，而且P1的LRQ上已經空了會怎麼樣？

圖2.12

圖2.12中，P2完成了它全部的工做，如今想要偷點什麼。首先，它會去看P1的LRQ卻發現什麼也沒有了。接下來他會去看GRQ。他會找到Goroutine-9

圖2.13

圖2.13中，P2從GRQ上偷走了Goroutine-9而且開始執行它的工做。這種work stealing的很大好處是，它讓M一直有事情作而不是閒下來。這種work stealing 能夠看作內部的M的輪轉，這種輪轉的好處在這篇博客裏作了很好的解釋。

實際例子

我想讓你看一下Go調度器爲了在同一時間裏作更多事情，這一切是如何一塊發生的。首先想象這樣一個多線程的C語言應用，程序須要處理兩個OS線程，他們倆互相進行通訊。

圖2.14

圖2.14中，有兩個線程，相互通訊。線程1上下文切換到Core1上而且如今正在執行，這容許線程1向線程2發送消息。

注意：通訊方式不重要。重要的是這個過程裏的線程狀態。

圖2.15

在圖2.15中，一旦線程1完成發送消息，它就須要等待響應。這會致使線程1從Core1切換下來並處於等待狀態。一旦線程2收到消息通知，它就會進入可執行的狀態。如今OS進行上下文切換而後線程2在一個Core2上面執行。接下來線程2處理消息而後給線程1發送一個新消息。

圖2.16

圖2.16裏。隨着線程1收到線程2的消息，又一次發生了上下文切換。如今線程2從執行中的狀態切換爲等待的狀態。而且線程1從等待狀態切換到了可執行狀態，最終回到運行狀態。如今線程1能夠處理併發送一個新消息回去。

全部的上下文切換(context switches)和狀態的改變都須要花費時間去處理，這就限制了工做速度。每一次上下文切換 會致使50ns的潛在延遲，硬件執行指令的指望時間是每ns 12個指令，你會看到上下文切換的時候就少執行600個指令。由於這些線程在不一樣的core以前切來切去，cache-line未命中致使的延遲也會增長。

咱們來看一下相同例子，使用Goroutines和Go調度器作替換。

圖2.17

圖2.17中，有兩個Goroutines相互傳遞消息。G1上下文切換到M1上進行工做處理，以前這都是在Core1上發生的事情。如今是G1向G2發送消息。

圖2.18

圖2.18中，一旦G1發送完消息，它就會等待響應返回。這會讓G1從M1上切換下來，而且進入到等到狀態。一旦G2收到消息通知，它會進入可執行狀態。如今Go調度器會把G2切換到M1上去執行，M1依舊在Core1上跑着。接下來G2處理消息而後給G1發送一個新消息。

圖2.19

在圖2.19中，隨着G1收到G2發送來的消息，又一次發生上下文切換。如今G2從執行中的狀態切換到等待狀態而且G1從等待中切換到可執行狀態，最終回到運行的狀態，G1又可以處理並向G2發送新的消息了。

表面上事情並無什麼不一樣。不論你使用線程仍是Goroutines都有上下文切換和狀態改變的過程。可是線程和Goroutines之間有一個重要的差異可能不會被明顯注意到。

在使用Goroutines的場景，整個過程一直使用的是相同的OS線程和Core。這也就意味着，從OS的視角，OS線程歷來沒有進入到waiting狀態，一次也沒有。結果就是咱們在線程中上下文切換丟失的指令在Goroutines中不會丟失。

本質上講，在OS層級go把io/blocking類型的工做轉變成了cpu密集型的工做。因爲全部上下文切換的過程都發生在應用程序的級別，上下文切換不會像線程同樣丟掉600個指令（平均來講）。Go調度器還有助於提升cache-line的效率和NUMA。這也是爲何咱們不須要比虛擬內核數更多的線程。在Go裏，隨着時間推移更多事情會被處理，由於Go調度器會嘗試用更少的線程而且每一個線程去作更多事情，這有助於減小OS和硬件層級的加載延遲。

結論

Go調度程序的設計在考慮操做系統和硬件工做複雜性方面確實使人驚訝。 在操做系統級別將IO /blocking工做轉換爲CPU密集型工做，是在利用更多CPU容量的過程當中得到巨大成功的地方。 這就是爲何你不須要比虛擬內核數更多的OS線程。 每一個虛擬內核一個OS線程狀況下，你能夠合理的指望你的全部工做(CPU密集、IO密集)都可以完成。對於網絡程序和那些不須要系統調用阻塞OS線程的程序，也可以完成。

做爲開發人員，你依舊須要理解在處理不一樣類型工做的時候你的程序正在作什麼。你不能爲了想要更好性能去無限制建立goroutine。Less is always more，可是經過理解了go調度器，你能夠更好的作出決定。下一部分，我會探討以保守的方式利用併發來提高性能的方法，可是對於代碼的複雜性仍是要作出平衡。

原文連接：www.ardanlabs.com/blog/2018/0…