如何有效控制 Go 线程数?
前陣子,在讀者交流群中有人提到 Go 默認設置的最大線程數的問題:如果超過一萬個 G (掛載于 M 上)阻塞于系統調用,那么程序就會被掛掉。
這是對的,因為 Go 對運行時創建的線程數量有一個限制,默認是 10000 個線程。今天我們就來探討一下 Go 線程數相關的問題。
閑置線程
相信對 Go 有所了解的人,對下圖所示的 GMP 模型不會陌生,每個 P 都會有一個操作系統線程 M 來執行其上的 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 的定義文檔,我們可以看到該變量只是限制了可以同時執行用戶級 Go 代碼的 OS 系統線程數量(通俗地講:Go 程序最多只能有和 P 相等個數的系統線程同時運行)。但是,在系統調用中被阻塞的線程不在此限制之中。
對于系統調用,可分為同步和異步兩種方式。
我們在《Go 網絡編程和 TCP 抓包實操》一文中闡述的 Go 網絡編程模型,就是一種異步系統調用。它使用網路輪詢器進行系統調用,調度器可以防止 G 在進行這些系統調用時阻塞 M。這可以讓 M 繼續執行其他的 G,而不需要創建新的 M。
但是,如果 G 要進行的是無法異步完成的系統調用時怎么辦?當網絡輪詢器無法使用時,進行系統調用的 G 將會阻塞 M。在 Linux 下基于普通文件(Linux 下的 epoll 只支持 socket,Windows 下的 iocp 可以支持 socket、file)的系統調用就是一個典型的例子。
同步系統調用 1如上圖所示,運行在 M1 上的 G1 想要請求一個同步系統調用。
同步系統調用 2當發生同步系統調用并阻塞時,調度器將 M1 和仍然掛載在其之上的 G1 與 P 分離,并引入新的 M2 來運行 P 上的其他 G。
同步系統調用 3當 G1 進行的阻塞式系統調用結束時,G1 重新回到 P 的 LRQ 中去,但 M1 變成了閑置線程,不會被回收,以留備后續復用。
問題來了,如果在某一短時段內,Go 程序存在大量無法短暫結束的同步系統調用,那線程數豈不是會一直漲下去?
最大線程數限制
線程數限制的問題,在官方 issues#4056: "runtime: limit number of operating system threads" 中,有過討論,并最終將線程限制數值確定為 10000。
這個值存在的主要目的是限制可以創建無限數量線程的 Go 程序:在程序把操作系統干爆之前,干掉程序。
當然,Go 也暴露了 debug.SetMaxThreads() 方法可以讓我們修改最大線程數值。
package?mainimport?("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) }如程序所示,我們將最大線程數設置為 10,然后通過執行 shell 命令 sleep 3 來模擬同步系統調用過程。那么,執行 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() 方法來殺死線程。
簡單了解下這個函數的特性:
調用 LockOSThread 函數會把當前 G 綁定在當前的系統線程 M 上,這個 G 總是在這個 M 上執行,并且阻止其它 G 在該 M 執行。
只有當前 G 調用了與之前調用 LockOSThread 相同次數的 UnlockOSThread 函數之后,G 與 M 才會解綁。
如果當前 G 在退出時,沒有調用 UnlockOSThread,這個線程會被終止。
那么,我們可以利用第三個特性,在啟動 G 時,調用 LockOSThread 來獨占一個 M。當 G 退出時,而不調用 UnlockOSThread,那這個 M 將不會被閑置,就被終止了。
下面,我們來看一個例子
package?mainimport?("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() 我們可以實時獲取當前線程數目,那么在發生了阻塞式系統調用后,該程序的線程數目是多少呢?
init?threads?counts:?5end?threads?counts:?25根據結果可以看到,G 執行完畢后,閑置線程并沒有被釋放。
在程序中添加一行代碼 runtime.LockOSThread() 代碼
go?func()?{runtime.LockOSThread()?//?增加的一行代碼_,?err?:=?exec.Command("bash",?"-c",?"sleep?3").Output()if?err?!=?nil?{panic(err)}}()此時,程序的執行結果如下
init?threads?counts:?5end?threads?counts:?11可以看到,由于調用了 LockOSThread 函數的 G 沒有執行 UnlockOSThread 函數,在 G 執行完畢后,M 也被終止了。
總結
在 GMP 模型中,P 與 M 一對一的掛載形式,通過設定 GOMAXPROCS 變量就能控制并行線程數。
當 M 遇到同步系統調用時,G 和 M 會與 P 剝離,當系統調用完成,G 重新進入可運行狀態,而 M 就會被閑置起來。
Go 目前并沒有對閑置線程做清除處理,它們被當作復用的資源,以備后續需要。但是,如果在 Go 程序中積累大量空閑線程,這是對資源的一種浪費,同時對操作系統也產生了威脅。因此,Go 設定了 10000 的默認線程數限制。
我們發現了一種利用 LockOSThread 函數的 trik 做法,可以借此做一些限制線程數的方案:例如啟動定期排查線程數的 goroutine,當發現程序的線程數超過某閾值后,就回收掉一部分閑置線程。
當然,這個方法也存在隱患。例如在 issues#14592 有人提到:當子進程由一個帶有 PdeathSignal: SIGKILL 的 A 線程創建,A 變為空閑時,如果 A 退出,那么子進程將會收到 KILL 信號,從而引起其他問題。
當然,絕大多數情況下,我們的 Go 程序并不會遇到空閑線程數過多的問題。如果真的存在線程數暴漲的問題,那么你應該思考代碼邏輯是否合理(為什么你能允許短時間內如此多的系統同步調用),是否可以做一些例如限流之類的處理。而不是想著通過 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 官方庫的第三方開源庫
Go 中如何強制關閉 TCP 連接
我終于識破了這個 Go 編譯器把戲
被遺棄在角落里的 sync.Cond
機器鈴砍菜刀
歡迎添加小菜刀微信
加入Golang分享群學習交流!
感謝你的點贊和在看哦~
總結
以上是生活随笔為你收集整理的如何有效控制 Go 线程数?的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 开发中的坑:MQ 也能做 RPC 调用?
- 下一篇: 看透 Go 对象内部细节的神器