Go Runtime的調度器

以goroutine形式進行Go併發編程是一種很是方便的方法，但有沒有想過他是如何有效地運行這些goroutine？下面從設計的角度，深刻了解和研究Go運行時調度程序，以及如何在性能調試過程當中使用它來解釋Go程序的調度程序跟蹤信息。

要了解爲何須要有一個運行時的調度以及它是如何工做的，先要回到操做系統的歷史上，在這裏將找到答案，由於若是不瞭解問題的根源。

操做系統的歷史

1. 單用戶（無操做系統）
2. 批處理 單編程 運行完成
3. 多程序

多程序的目的是使CPU和I/O重疊。如何作到的呢？

• 多批次
  IBM OS / MFT（具備固定數量的任務的多重編程）
• 多批次
  IBM OS / MVT（具備可變數量的任務的多重編程）—在這裏，每一個做業僅得到其所需的內存量。即，隨着做業的進出，內存的分區發生變化。
• 分時
  這是在做業之間快速切換的多道程序設計。決定什麼時候切換以及切換到哪些做業稱爲調度。

現代大多數操做系統使用分時調度程序。

這些調度程序調度的是什麼呢？
1 不一樣的程序正在執行（進程）
2 做爲進程子集存在的CPU利用率（線程）的基本單位

這些都是有代價的。

調度成本

所以，使用一個包含多個線程的進程效率更高，由於進程建立既耗時又耗費資源。隨後出現了多線程問題：C10k問題是主要的問題。

例如，若是將調度程序週期定義爲10毫秒（毫秒），而且有2個線程，則每一個線程將分別得到5毫秒。若是您有5個線程，則每一個線程將得到2ms。可是，若是有1000個線程怎麼辦？給每一個線程10s（微秒）的時間片？你將花費大量時間進行上下文切換，可是沒法完成真正的工做。

你須要限制時間片的長度。在最後一種狀況下，若是最小時間片是2ms，而且有1000個線程，則調度程序週期須要增長到2s（秒）。若是有10,000個線程，則調度程序週期爲20秒。在這個簡單的示例中，若是每一個線程都使用其全時切片，則全部線程一次運行須要20秒。所以，咱們須要一些可使併發成本下降而又不會形成過多開銷的東西。

用戶級線程
• 線程徹底由運行時系統（用戶級庫）管理。
• 理想狀況下，快速高效：切換線程不比函數調用貴多少。
• 內核對用戶級線程一無所知，並像對待單線程進程同樣對其進行管理。

在Go中，咱們叫它「 Goroutine」（在邏輯上）

Goroutine

協程是輕量級線程，由Go運行時管理（邏輯上一個執行的線程）。要go在函數調用以前啓動運行go關鍵字。

func main() {
    var wg sync.WaitGroup
    wg.Add(11)
    for i := 0; i <= 10; i++ {
   
        go func(i int) {
          defer wg.Done()
          fmt.Printf("loop i is - %d\n", i)
        }(i)
    }
    wg.Wait()
    fmt.Println("Hello, Welcome to Go")
}
運行結果

loop i is - 10
loop i is - 0
loop i is - 1
loop i is - 2
loop i is - 3
loop i is - 4
loop i is - 5
loop i is - 6
loop i is - 7
loop i is - 8
loop i is - 9
Hello, Welcome to Go

看一下輸出，就會有兩個問題。

1. 11個goroutine如何併發運行的？
2. goroutine以什麼順序運行？

這兩個問題，又引起新的思考：

1. 如何將這些多個 goroutine 分佈到在可用 CPU 處理器上運行的多個 OS 線程上。
2. 這些多個 goroutine 應該以什麼順序運行以保持公平性？

其他的討論將主要圍繞從設計角度解決 Go 運行時調度程序的這些問題。調度程序可能會瞄準許多目標中的一個或多個，對於咱們的案例，咱們將限制本身知足如下要求。

1. 應該是並行的、可擴展的、公平的。
2. 每一個進程應可擴展到數百萬個goroutine（10⁶）
3. 內存高效。（RAM很便宜，但不是免費的。）
4. 系統調用不該致使性能降低。（最大化吞吐量，最小化等待時間）

所以，讓咱們開始爲調度程序建模，以逐步解決這些問題。

1.每一個Goroutine線程——用戶級線程。

  限制

    1.並行和可擴展。
      * 並行
      * 可擴展
    2. 每一個進程不能擴展到數百萬個goroutine（10⁶）

2.M:N線程——混合線程

M個內核線程執行N個「 goroutine」

M個內核線程執行N個「 goroutine」

代碼和並行的實際執行須要內核線程。可是建立成本很高，因此將 N 個 goroutine 映射到 M Kernel Thread。Goroutine 是 Go Code，因此咱們能夠徹底控制它。此外，它在用戶空間中，所以建立起來很便宜。

可是由於操做系統對 goroutine 一無所知。每一個 goroutine 都有一個 state 來幫助Scheduler根據 goroutine state 知道要運行哪一個 goroutine。與內核線程相比，這個狀態信息很小，goroutine 的上下文切換變得很是快。

• Running-當前在內核線程上運行的goroutine。
• Runnable-夠程等待內核線程來運行。
• Blocked-等待某些條件的Goroutine（例如，在通道，系統調用，互斥體等上被阻止）

2個線程一次運行2個

所以，Go Runtime Scheduler經過將N Goroutine複用到M內核線程來管理處於各類狀態的這些goroutine。

簡單的MN排程器
在咱們簡單的M:N Scheduler中，咱們有一個全局運行隊列，某些操做將一個新的goroutine放入運行隊列。M個內核線程訪問調度程序以從「運行隊列」中獲取goroutine來運行。多個線程嘗試訪問相同的內存區域，咱們將使用Mutex For Memory Access Synchronization鎖定此結構。

簡單的M:N

阻塞的goroutine在哪裏？
能夠阻塞的goroutine一些實例。

1. 在channel上發送和接收。
2. 網絡I/O。
3. 阻止系統調用。
4. 計時器。
5. 互斥體。

那麼，咱們將這些阻塞的goroutine放在哪裏？

阻塞的goroutine不該阻塞底層的內核線程！（避免線程上下文切換成本）

通道操做期間阻止了Goroutine。
每一個通道都有一個recvq（waitq），用於存儲被阻止的goroutine，這些goroutine試圖從該通道讀取數據。
Sendq（waitq）存儲試圖將數據發送到通道的被阻止的goroutine 。

通道操做期間阻止了Goroutine。

通道操做後的未阻塞的goroutine被通道放入「運行」隊列。

通道操做後接觸阻塞的goroutine

系統調用呢？

首先，讓咱們看看阻塞系統調用。一個阻塞底層內核線程的系統調用，因此咱們不能在這個線程上調度任何其餘 Goroutine。

隱含阻塞系統調用下降了並行級別。

不能在 M2 線程上調度任何其餘 Goroutine，致使CPU 浪費。

咱們能夠恢復並行度的方法是，當咱們進入系統調用時，咱們能夠喚醒另外一個線程，該線程將從運行隊列中選擇可運行的 goroutine。

如今，當系統調用完成時，超額執行了Groutine計劃。爲了不這種狀況，咱們不會當即運行Goroutine從阻止系統調用中返回。可是咱們會將其放入調度程序運行隊列中。

避免過分預約的調度

所以，當咱們的程序運行時，線程數大於內核數。儘管沒有明確說明，線程數大於內核數，而且全部空閒線程也都由運行時管理，以免過多的線程。

初始設置爲10,000個線程，若是超過則程序崩潰。

非阻塞系統調用---在集成運行時輪詢器上阻塞 goroutine ，並釋放線程以運行另外一個 goroutine。

例如在非阻塞 I/O 的狀況下，例如 HTTP 調用。第一個系統調用 - 遵循先前的工做流程 - 不會成功，由於資源還沒有準備好，迫使 Go 使用網絡輪詢器並停放 goroutine。

這是部分 net.Read功能的實現。

n, err := syscall.Read(fd.Sysfd, p)
if err != nil {
  n = 0
  if err == syscall.EAGAIN && fd.pd.pollable() {
    if err = fd.pd.waitRead(fd.isFile); err == nil {
    continue
  }
}

一旦完成第一個系統調用並明確指出資源還沒有準備好，goroutine將停放，直到網絡輪詢器通知它資源已準備好爲止。在這種狀況下，線程M將不會被阻塞。

Poller將基於操做系統使用select/kqueue/epoll/IOCP來了解哪一個文件描述符已準備好，一旦文件描述符準備好進行讀取或寫入，它將把goroutine放回到運行隊列中。

還有一個Sysmon OS線程，若是輪詢時間不超過10毫秒，它將按期輪詢網絡，並將就緒G添加到隊列中。

基本上全部的goroutine都被阻止在

1. 渠道
2. 互斥體
3. 網絡IO
4. 計時器

如今，運行時具備具備如下功能的調度程序。

• 它能夠處理並行執行（多線程）。
• 處理阻止系統調用和網絡I/O。
• 處理阻止用戶級別（在通道上）的調用。

但這不是可擴展的

使用Mutex的全局運行隊列

如圖所見，咱們有一個Mutex全局運行隊列，最終會遇到一些問題，例如

1. 緩存一致性保證的開銷。
2. 在建立，銷燬和調度Goroutine G時進行激烈的鎖爭用。

使用分佈式調度器克服可擴展性的問題。

分佈式調度程序—每一個線程運行隊列。

分佈式運行隊列調度程序

這樣，咱們能夠看到的直接好處是，對於每一個線程本地運行隊列，咱們如今都沒有互斥體。仍然有一個帶有互斥量的全局運行隊列，在特殊狀況下使用。它不會影響可伸縮性。

如今，咱們有多個運行隊列。

1. 本地運行隊列
2. 全局運行隊列
3. 網絡輪訓器

咱們應該從哪裏運行下一個goroutine？

在Go中，輪詢順序定義以下。

1. 本地運行隊列
2. 全局運行隊列
3. 網絡輪訓器
4. 工做偷竊（Work Stealing）

即首先檢查本地運行隊列，若是爲空則檢查全局運行隊列，而後檢查網絡輪詢器，最後進行竊取工做。到目前爲止，咱們對1,2,3有了一些概述。讓咱們看一下「竊取工做」。

工做偷竊

若是本地工做隊列爲空，請嘗試「從其餘隊列中竊取工做」

「偷竊」工做

當一個線程有太多的工做要作而另外一個線程處於空閒狀態時，工做竊取解決了這個問題。在Go中，若是本地隊列爲空，竊取工做將嘗試知足如下條件之一。

• 從全局隊列中拉取工做。
• 從網絡輪詢器中拉取工做。
• 從其餘本地隊列中竊取工做。

到目前爲止，運行時Go具備具備如下功能的Scheduler。

• 它能夠處理並行執行（多線程）。
• 處理阻止系統調用和網絡I/O。
• 處理阻止用戶級別（在通道上）的調用。
• 可擴展

但這不是有效的。

還記得咱們在阻塞系統調用中恢復並行度的方式嗎？

它的含義是，在一個系統調用中咱們能夠有多個內核線程（能夠是10或1000），這可能會增長內核數。咱們最終在如下期間產生了恆定的開銷：

• 竊取工做時，它必須同時掃描全部內核線程（理想狀況下並使用goroutine運行）本地運行隊列，而且大多數都將爲空。
• 垃圾回收，內存分配器都遭受相同的掃描問題。

使用M:P:N線程克服效率問題。

3.M：P：N（3級調度程序）線程化—邏輯處理器P簡介

P — 處理器，能夠將其視爲在線程上運行的本地調度程序；

M:P:N線程

邏輯進程P的數量始終是固定的。（默認爲當前進程可使用的邏輯CPU）

將本地運行隊列（LRQ）放入固定數量的邏輯處理器（P）中。

分佈式三級運行隊列調度程序

Go運行時將首先根據計算機的邏輯CPU數量（或根據請求）建立固定數量的邏輯處理器P。

每一個goroutine（G）將在分配給邏輯CPU（P）的OS線程（M）上運行。

所以，如今咱們在如下期間沒有固定的開銷：

• 竊取工做-只需掃描固定數量的邏輯處理器（P）本地運行隊列。
• 垃圾回收，內存分配器也得到相同的好處。

帶有固定邏輯處理器（P）的系統調用怎麼樣？

Go經過將系統調用包裝在運行時中來優化系統調用-不管它是否阻塞

阻止系統調用包裝器

Blocking SYSCALL方法封裝在runtime.entersyscall（SB）
runtime.exitsyscall（SB）之間。
從字面上看，某些邏輯在進入系統調用以前執行，而某些邏輯在退出系統調用以後執行。進行阻塞系統調用時，此包裝器將自動從線程M分離P，並容許另外一個線程在其上運行。

阻塞系統調用切換P

這容許 Go 運行時在不增長運行隊列的狀況下有效地處理阻塞系統調用。

一旦阻止syscall退出，會發生什麼？

• 運行時嘗試獲取徹底相同的P，而後繼續執行。
• 運行時嘗試在空閒列表中獲取一個P並恢復執行。
• 運行時將goroutine放到全局隊列中，並將關聯的M放回空閒列表。

自旋線程和理想線程（Spinning Thread and Ideal Thread）.

當M2線程在syscall返回後變成理想理想線程時。該理想的M2線程該怎麼辦。理論上，一個線程若是完成了它須要作的事情就應該被操做系統銷燬，而後其餘進程中的線程可能會被 CPU 調度執行。這就是咱們常說的操做系統中線程的「搶佔式調度」。

考慮上述syscall中的狀況。若是咱們銷燬了M2線程，而M3線程即將進入syscall。此時，在建立新的內核線程並將其計劃由OS執行以前，沒法處理可運行的goroutine。頻繁的線程前搶佔操做不只會增長OS的負載，並且對於性能要求更高的程序幾乎是不可接受的。

所以，爲了正確利用操做系統的資源並防止頻繁的線程搶佔操做系統上的負載，咱們不會破壞內核線程M2，而是進行自旋操做並保存以備未來使用。儘管這彷佛是在浪費一些資源。可是，與線程之間的頻繁搶佔以及頻繁的建立和銷燬操做相比，「理想的線程」仍然要付出更少的代價。

Spinning Thread —例如，在具備一個內核線程M（1）和一個邏輯處理器（P）的Go程序中，若是正在執行的M被syscall阻止，則「 Spinning Threads」的數目與該數目相同須要P的值以容許等待的可運行goroutine繼續執行。所以，在此期間，內核線程的數量M大於P的數量（旋轉線程+阻塞線程）。所以，即便將runtime.GOMAXPROCSvalue設置爲1，程序也將處於多線程狀態。

調度中的公平性如何？—公平選擇下一步要執行的goroutine。

與許多其餘調度程序同樣，Go也具備公平性約束，而且由goroutine的實現所強加，由於Runnable goroutine應該最終運行

如下是Go Runtime Scheduler中的四個典型的公平性約束。

任何運行超過 10 毫秒的 goroutine 都被標記爲可搶佔（軟限制）。可是，搶佔僅在函數序言中完成。Go 目前在函數 prologues 中使用編譯器插入的合做搶佔點。

    無限循環——搶佔（~10ms 時間片）——軟限制

可是要當心無限循環，由於 Go 的調度程序不是搶佔式的（直到 1.13）。若是循環不包含任何搶佔點（如函數調用或分配內存），它們將阻止其餘 goroutine 運行。一個簡單的例子是：

package main
func main() {
    go println("goroutine ran")
    for {}
}

執行命令

GOMAXPROCS = 1 go run main.go

直到Go（1.13）纔可能打印該語句。因爲缺乏搶佔點，所以主要的Goroutine能夠佔用處理器。

• 本地運行隊列-搶佔（〜10ms時間片）-軟限制
• 經過每61個調度程序刻度檢查一次全局運行隊列，能夠避免全局運行隊列飢餓。
• Network Poller Starvation後臺線程輪詢網絡偶爾會被主工做線程輪詢。

Go 1.14有一個新的「非合做式搶佔」。

有了Go，Runtime有了一個Scheduler，它具備全部必需的功能。

• 它能夠處理並行執行（多線程）。
• 處理阻止系統調用和網絡I / O。
• 處理阻止用戶級別（在通道上）的調用。
• 可擴展
• 高效的。
• 公平的。

這提供了大量的併發性，而且始終嘗試實現最大的利用率和最小的延遲。

如今，咱們整體上對Go運行時調度程序有了一些瞭解，咱們如何使用它？Go爲咱們提供了一個跟蹤工具，即調度程序跟蹤，目的是提供有關行爲的看法並調試與goroutine調度程序有關的可伸縮性問題。

調度程序跟蹤

使用GODEBUG = schedtrace = DURATION環境變量運行Go程序以啓用調度程序跟蹤。（DURATION是以毫秒爲單位的輸出週期。）