Go:併發和調度程序親和性

將一個goroutine從一個OS線程切換到另外一個線程是有成本的，而且若是這種狀況發生得太頻繁，可能會使應用程序變慢。可是，隨着時間的流逝，Go調度程序已經解決了這個問題。如今，當併發工做時，它能夠在goroutine和線程之間提供關聯。讓咱們回溯幾年前來了解這種改進。

原始問題

在Go的早期，好比Go 1.0和1.1，當使用更多OS線程（即，更高的GOMAXPROCS值）運行併發代碼時，該語言將面臨性能降低的問題。讓咱們從計算素數的文檔中使用一個示例開始：

這是使用多個GOMAXPROCS值計算前十萬個素數時Go 1.0.3的基準：

name time/op  
Sieve 19.2s ± 0%  
Sieve-2 19.3s ± 0%  
Sieve-4 20.4s ± 0%  
Sieve-8 20.4s ± 0%

要了解這些結果，咱們須要瞭解此時如何設計調度程序。在Go的第一個版本中，調度程序只有一個全局隊列，全部線程均可以在其中推送並獲取goroutine。這是一個應用程序的示例，該應用程序最多將兩個操做系統線程（如下架構中的M）運行（經過將GOMAXPROCS設置爲兩個來定義）：

僅具備一個隊列並不能保證goroutine將在同一線程上恢復。準備就緒的第一個線程將提取一個等待的goroutine並將其運行。所以，它涉及將goroutines從一個線程轉移到另外一個線程，而且在性能方面代價很高。這是一個帶有阻塞通道的示例：

• Goroutine＃7在通道上阻塞，正在等待消息。收到消息後，goroutine將推入全局隊列：

• 而後，通道推送消息，而且goroutine #X將在可用線程上運行，而goroutine＃8在通道上阻塞：

• goroutine＃7如今在可用線程上運行：

如今，goroutine在不一樣的線程上運行。具備單個全局隊列也將迫使調度程序具備一個覆蓋全部goroutines調度操做的單個全局互斥量。這是使用pprof建立的CPU配置文件，其中GOMAXPROCS設置爲height：

Total: 8679 samples  
3700 42.6% 42.6% 3700 42.6% runtime.procyield  
1055 12.2% 54.8% 1055 12.2% runtime.xchg  
753 8.7% 63.5% 1590 18.3% runtime.chanrecv  
677 7.8% 71.3% 677 7.8% dequeue  
438 5.0% 76.3% 438 5.0% runtime.futex  
367 4.2% 80.5% 5924 68.3% main.filter  
234 2.7% 83.2% 5005 57.7% runtime.lock  
230 2.7% 85.9% 3933 45.3% runtime.chansend  
214 2.5% 88.4% 214 2.5% runtime.osyield  
150 1.7% 90.1% 150 1.7% runtime.cas

procyield，xchg，futex和lock都與Go調度程序的全局互斥量有關。咱們清楚地看到，應用程序將大部分時間都花在了鎖定上。

這些問題不容許Go發揮處理器的優點，而且在Go 1.1中使用新的調度程序解決了這些問題。

併發中的親和性

Go 1.1附帶了新調度程序的實現和本地goroutine隊列的建立。若是存在本地goroutine，此改進避免了鎖定整個調度程序，並容許它們在同一OS線程上工做。

因爲線程能夠阻塞系統調用，而且不受限制的線程數沒有限制，所以Go引入了處理器的概念。處理器P表明一個正在運行的OS線程，它將管理本地goroutine隊列。這是新的架構：

這是Go 1.1.2中新計劃程序的新基準：

name time/op  
Sieve 18.7s ± 0%  
Sieve-2 8.26s ± 0%  
Sieve-4 3.30s ± 0%  
Sieve-8 2.64s ± 0%

Go如今真正利用了全部可用的CPU。 CPU配置文件也已更改：

Total: 630 samples  
163 25.9% 25.9% 163 25.9% runtime.xchg  
113 17.9% 43.8% 610 96.8% main.filter  
93 14.8% 58.6% 265 42.1% runtime.chanrecv  
87 13.8% 72.4% 206 32.7% runtime.chansend  
72 11.4% 83.8% 72 11.4% dequeue  
19 3.0% 86.8% 19 3.0% runtime.memcopy64  
17 2.7% 89.5% 225 35.7% runtime.chansend1  
16 2.5% 92.1% 280 44.4% runtime.chanrecv2  
12 1.9% 94.0% 141 22.4% runtime.lock  
9 1.4% 95.4% 98 15.6% runqput

與鎖定相關的大多數操做已被刪除，標記爲chanXXXX的操做僅與通道相關。可是，若是調度程序改善了goroutine和線程之間的親和力，則在某些狀況下能夠減小這種親和力。

親和性限制

要了解親和性的限制，咱們必須瞭解對本地和全局隊列的處理。本地隊列將用於全部須要系統調用的操做，例如阻塞通道和選擇的操做，等待計時器和鎖定。可是，兩個功能可能會限制goroutine和線程之間的關聯：

• Worker搶奪。當處理器 P 的本地隊列中沒有足夠的worker時，若是全局隊列和網絡輪詢器爲空，它將從其餘 P 竊取goroutine。當被搶奪時，goroutine將在另外一個線程上運行。
• 系統調用。當發生系統調用時（例如文件操做，http調用，數據庫操做等），Go會將運行中的OS線程移入阻塞模式，讓新線程處理當前P上的本地隊列。

可是，經過更好地管理本地隊列的優先級，能夠避免這兩個限制。 Go 1.5旨在爲goroutine在通道上來回通訊提供更高的優先級，從而優化與分配的線程的親和力。

爲了加強親和力

如前所述，在通道上來回通訊的goroutine會致使頻繁的阻塞，即在本地隊列中頻繁地從新排隊。可是，因爲本地隊列具備FIFO實現，所以，若是另外一個goroutine正在佔用線程，則unblock goroutine不能保證儘快運行。這是一個goroutine的示例，該例程如今能夠運行而且之前在通道上被阻止：

Goroutine＃9在通道上被阻塞後恢復。可是，它必須在運行以前等待＃2，＃5和＃4。在此示例中，goroutine＃5將佔用其線程，從而延遲goroutine＃9，並使之處於被其餘處理器竊取的危險中。從Go 1.5開始，因爲其 P 的特殊屬性，從阻塞通道返回的goroutine如今將優先運行：

Goroutine＃9如今被標記爲下一個可運行的。這種新的優先級劃分功能使goroutine能夠在再次被阻塞以前迅速運行。而後，其餘goroutine將具備運行時間。此更改對Go標準庫改善了某些軟件包的性能產生了整體積極影響。