[譯]Go：Goroutine, OS線程 以及 CPU管理

原文https://medium.com/a-journey-with-go/go-goroutine-os-thread-and-cpu-management-2f5a5eaf518a

操做系統的線程建立以及切換是須要開銷的，會影響程序的性能。Go致力於儘量地從內核中獲取優點，因此從最開始的時候設計就考慮到了併發性。

M，P，G 編排

爲了解決這個問題，Go有他本身的調度者，負責在線程上分配goroutines。這個協調者由3個概念組成，以下：

The main concepts are:
G - goroutine.
M - worker thread, or machine. 工做線程或機器
P - processor, a resource that is required to execute Go code.
    M must have an associated P to execute Go code[...].
    處理者，負責執行Go代碼， 每一個M必須有一個關聯的P去執行Go代碼
複製代碼

三者關係圖以下：

每個goruntine（G）運行在操做系統線程（M）上並分配一個邏輯CPU（P）。咱們用一個簡單的例子來看看Go是如何管理他們的：

func main() {
   var wg sync.WaitGroup
   wg.Add(2)

   go func() {
      println(`hello`)
      wg.Done()
   }()

   go func() {
      println(`world`)
      wg.Done()
   }()

   wg.Wait()
}
複製代碼

Go首先會基於機器邏輯CPUs的數量來建立不一樣的P，並將他們儲存成一個空閒的P的列表

而後，當新的goroutine或者goroutine準備運行的時候會喚醒一個空閒的P，這個P會建立一個關聯到操做系統線程的M

然而，當P，M不工做的，假如，沒有goruntine在等待被執行的時候，就會返回一個系統調用syscall，或者甚至被垃圾回收強制中止，放回空閒P/M鏈表中。

在程序運行時候，Go已經建立了一些OS線程以及關聯上M。在咱們的例子中，第一個負責打印hello的goroutine會使用主goroutine， 而第二個goroutine從空閒列表中獲取一個P和M

如今咱們已經對goroutines以及線程管理有一個大概瞭解了，讓咱們看看在何時Go會出現M數量比P多的狀況以及goroutines是如何管理這種系統調用的。

系統調用 System calls

Go經過在運行時封裝系統調用來進行優化，不管阻塞與否。這個封裝會自動將P與M的關聯切斷，而後容許第二個線程M來運行P。咱們來看看下面一個讀取文件例子：

func main() {
   buf := make([]byte, 0, 2)

   fd, _ := os.Open("number.txt")
   fd.Read(buf)
   fd.Close()

   println(string(buf)) // 42
}
複製代碼

下面是圖片演示整個執行過程

P0如今在空閒列表中處於可被使用狀態。一旦系統調用退出時，Go遵循下面的規制直到其中一個條件知足

• 嘗試去得到一個如出一轍的P，在咱們的例子中就是P0，而後恢復執行
• 嘗試獲取空閒列表中的P，而後恢復執行
• 將goroutine到全局隊列中，而後將其關聯的M放回到空閒列表中

然而，Go一樣須要處理當資源還沒準備好的狀況，例如HTTP請求這種非阻塞I/O。在這種狀況下，第一個系統調用，一樣會遵循上述規制可是不會成功，由於資源尚未準備好，這時會強迫Go使用network poller以及暫停goroutine。以下例子：

func main() {
   http.Get(`https://httpstat.us/200`)
}
複製代碼

當第一個系統調用執行完成並明確地說資源還沒準備好的時候，goroutine會暫停直到network poller通知其說資源已經準備好了。在這種狀況下，線程M是不會被阻塞的。

當Go協調程序從新查找待完成工做時，goroutine會被從新執行一次。這個協調者在成功獲取一個他所等待的消息之後，會問network poller是否有goroutine在等待運行。

若是有多於一個goroutine準備好的時候，其他的goroutine會進入全局的可執行隊列中等待被執行。

OS線程的限制 Restriction in term of OS threads

當系統調用時，Go不會限制能夠阻塞的OS線程的數量，官方解釋：

GOMAXPROCS變量限制了能夠同時執行用戶級Go代碼的操做系統線程的數量。 對於表明Go代碼的系統調用中能夠阻止的線程數量沒有限制； GOMAXPROCS函數可查詢並更改限制。

這段代碼解釋這個狀況

func main() {
   var wg sync.WaitGroup

   for i := 0;i < 100 ;i++  {
      wg.Add(1)

      go func() {
         http.Get(`https://httpstat.us/200?sleep=10000`)

         wg.Done()
      }()
   }

   wg.Wait()
}
複製代碼

下面是跟蹤工具裏面展現的線程數量

因爲Go將線程的使用進行了優化，當goroutines被阻塞時候能夠被從新利用，也就解釋了爲何這個數與循環數並不匹配。