引言

前陣子，在讀者交流群中有人提到 Go 默認設置的最大線程數(shù)的問題：如果超過一萬個 G （掛載于 M 上）阻塞于系統(tǒng)調用，那么程序就會被掛掉。

這是對的，因為 Go 對運行時創(chuàng)建的線程數(shù)量有一個限制，默認是 10000 個線程。今天我們就來探討一下 Go 線程數(shù)相關的問題。

閑置線程

相信對 Go 有所了解的人，對下圖所示的 GMP 模型不會陌生，每個 P 都會有一個操作系統(tǒng)線程 M 來執(zhí)行其上的 G。

GMP 模型

我們可以通過設置 GOMAXPROCS 來設定 P 的最大值，這個值代表什么含義呢?

The GOMAXPROCS variable limits the number of operating system threads that
can execute user-level Go code simultaneously. There is no limit to the number of threads
that can be blocked in system calls on behalf of Go code; those do not count against
the GOMAXPROCS limit. This package's GOMAXPROCS function queries and changes
the limit.

通過 GOMAXPROCS 的定義文檔，我們可以看到該變量只是限制了可以同時執(zhí)行用戶級 Go 代碼的 OS 系統(tǒng)線程數(shù)量（通俗地講：Go 程序最多只能有和 P 相等個數(shù)的系統(tǒng)線程同時運行）。但是，在系統(tǒng)調用中被阻塞的線程不在此限制之中。

對于系統(tǒng)調用，可分為同步和異步兩種方式。

我們在《Go 網絡編程和 TCP 抓包實操》一文中闡述的 Go 網絡編程模型，就是一種異步系統(tǒng)調用。它使用網路輪詢器進行系統(tǒng)調用，調度器可以防止 G 在進行這些系統(tǒng)調用時阻塞 M。這可以讓 M 繼續(xù)執(zhí)行其他的 G，而不需要創(chuàng)建新的 M。

但是，如果 G 要進行的是無法異步完成的系統(tǒng)調用時怎么辦？當網絡輪詢器無法使用時，進行系統(tǒng)調用的 G 將會阻塞 M。在 Linux 下基于普通文件（Linux 下的 epoll 只支持 socket，Windows 下的 iocp 可以支持 socket、file）的系統(tǒng)調用就是一個典型的例子。

同步系統(tǒng)調用 1

如上圖所示，運行在 M1 上的 G1 想要請求一個同步系統(tǒng)調用。

同步系統(tǒng)調用 2

當發(fā)生同步系統(tǒng)調用并阻塞時，調度器將 M1 和仍然掛載在其之上的 G1 與 P 分離，并引入新的 M2 來運行 P 上的其他 G。

同步系統(tǒng)調用 3

當 G1 進行的阻塞式系統(tǒng)調用結束時，G1 重新回到 P 的 LRQ 中去，但 M1 變成了閑置線程，不會被回收，以留備后續(xù)復用。

問題來了，如果在某一短時段內，Go 程序存在大量無法短暫結束的同步系統(tǒng)調用，那線程數(shù)豈不是會一直漲下去？

最大線程數(shù)限制

線程數(shù)限制的問題，在官方 issues#4056: "runtime: limit number of operating system threads" 中，有過討論，并最終將線程限制數(shù)值確定為 10000。

這個值存在的主要目的是限制可以創(chuàng)建無限數(shù)量線程的 Go 程序：在程序把操作系統(tǒng)干爆之前，干掉程序。

當然，Go 也暴露了 debug.SetMaxThreads() 方法可以讓我們修改最大線程數(shù)值。

package main

import (
 "os/exec"
 "runtime/debug"
 "time"
)

func main() {
 debug.SetMaxThreads(10)
 for i := 0; i < 20; i++ {
  go func() {
   _, err := exec.Command("bash", "-c", "sleep 3").Output()
   if err != nil {
    panic(err)
   }
  }()
 }
 time.Sleep(time.Second * 5)
}

如程序所示，我們將最大線程數(shù)設置為 10，然后通過執(zhí)行 shell 命令 sleep 3 來模擬同步系統(tǒng)調用過程。那么，執(zhí)行 sleep 操作的 G 和 M 都會阻塞，當程序啟動的線程 M 超過 10 個時，會得到以下報錯。

runtime: program exceeds 10-thread limit
fatal error: thread exhaustion
***

讓閑置線程退出

閑置線程退出的問題，在官方 issues#14592: "runtime: let idle OS threads exit" 中有過討論。目前，還沒有一個完美的解決方案。

但是，在該 issue 里有人提出使用 runtime.LockOSThread() 方法來殺死線程。

簡單了解下這個函數(shù)的特性：

• 調用 LockOSThread 函數(shù)會把當前 G 綁定在當前的系統(tǒng)線程 M 上，這個 G 總是在這個 M 上執(zhí)行，并且阻止其它 G 在該 M 執(zhí)行。

• 只有當前 G 調用了與之前調用 LockOSThread 相同次數(shù)的 UnlockOSThread 函數(shù)之后，G 與 M 才會解綁。

• 如果當前 G 在退出時，沒有調用 UnlockOSThread，這個線程會被終止。

那么，我們可以利用第三個特性，在啟動 G 時，調用 LockOSThread 來獨占一個 M。當 G 退出時，而不調用 UnlockOSThread，那這個 M 將不會被閑置，就被終止了。

下面，我們來看一個例子

package main

import (
 "fmt"
 "os/exec"
 "runtime/pprof"
 "time"
)

func main() {
 threadProfile := pprof.Lookup("threadcreate")
 fmt.Printf(" init threads counts: %d\n", threadProfile.Count())

 for i := 0; i < 20; i++ {
  go func() {
   _, err := exec.Command("bash", "-c", "sleep 3").Output()
   if err != nil {
    panic(err)
   }
  }()
 }
 time.Sleep(time.Second * 5)
 fmt.Printf(" end threads counts: %d\n", threadProfile.Count())
}

通過 threadProfile.Count() 我們可以實時獲取當前線程數(shù)目，那么在發(fā)生了阻塞式系統(tǒng)調用后，該程序的線程數(shù)目是多少呢？

 init threads counts: 5
 end threads counts: 25

根據(jù)結果可以看到，G 執(zhí)行完畢后，閑置線程并沒有被釋放。

在程序中添加一行代碼 runtime.LockOSThread() 代碼

  go func() {
   runtime.LockOSThread() // 增加的一行代碼
   _, err := exec.Command("bash", "-c", "sleep 3").Output()
   if err != nil {
    panic(err)
   }
  }()

此時，程序的執(zhí)行結果如下

 init threads counts: 5
 end threads counts: 11

可以看到，由于調用了 LockOSThread 函數(shù)的 G 沒有執(zhí)行 UnlockOSThread 函數(shù)，在 G 執(zhí)行完畢后，M 也被終止了。

總結

在 GMP 模型中，P 與 M 一對一的掛載形式，通過設定 GOMAXPROCS 變量就能控制并行線程數(shù)。

當 M 遇到同步系統(tǒng)調用時，G 和 M 會與 P 剝離，當系統(tǒng)調用完成，G 重新進入可運行狀態(tài)，而 M 就會被閑置起來。

Go 目前并沒有對閑置線程做清除處理，它們被當作復用的資源，以備后續(xù)需要。但是，如果在 Go 程序中積累大量空閑線程，這是對資源的一種浪費，同時對操作系統(tǒng)也產生了威脅。因此，Go 設定了 10000 的默認線程數(shù)限制。

我們發(fā)現(xiàn)了一種利用 LockOSThread 函數(shù)的 trik 做法，可以借此做一些限制線程數(shù)的方案：例如啟動定期排查線程數(shù)的 goroutine，當發(fā)現(xiàn)程序的線程數(shù)超過某閾值后，就回收掉一部分閑置線程。

當然，這個方法也存在隱患。例如在 issues#14592 有人提到：當子進程由一個帶有 PdeathSignal: SIGKILL 的 A 線程創(chuàng)建，A 變?yōu)榭臻e時，如果 A 退出，那么子進程將會收到 KILL 信號，從而引起其他問題。

當然，絕大多數(shù)情況下，我們的 Go 程序并不會遇到空閑線程數(shù)過多的問題。如果真的存在線程數(shù)暴漲的問題，那么你應該思考代碼邏輯是否合理（為什么你能允許短時間內如此多的系統(tǒng)同步調用），是否可以做一些例如限流之類的處理。而不是想著通過 SetMaxThreads 方法來處理。

參考

Scheduling In Go：

https://www.ardanlabs.com/blog/2018/08/scheduling-in-go-part2.html 

issues#4056：

https://github.com/golang/go/issues/4056 

issues#14592：

https://github.com/golang/go/issues/14592 

以上就是如何有效控制 Go 線程數(shù)的詳細內容，更多關于Go線程數(shù)控制 的資料請關注腳本之家其它相關文章！

最新評論