Golang 學習之併發機制

【導讀】golang 併發機制和其他語言在實現上有什麼不同?爲什麼能做到高效快速?本文做了詳細介紹。

由於對普通語法的介紹網上資源極多,Go 官方的上手指南 A Tour of Go: https://tour.golang.org/ (請自備梯子)就是極好的例子,我不再打算就語法細節進行詳述。這次,讓我們直切肯綮,從 Go 最大的賣點入手——併發 (Concurrency)。

func Hello() {
    fmt.Println("I'm B")        // Output A
}
go Hello()
fmt.Println("I'm A")            // Output B

如果在雙核(及以上)的機器編譯運行上述 Go 代碼,我們能觀測到 A/B 輸出的順序隨着運行次數的不同而不同,也就是說,僅依靠 5 行代碼,我們就創建了兩線併發的程序。相較於 C/C++/Java/Python 等語言爲了創建一個併發執行環境所需要的調用 POSIX-API / 定義繼承類等繁瑣步驟,Golang 簡單一句 go func()的確給人眼前一亮的感覺。當然了,僅憑語法上的簡潔顯然不足以成爲一個編程語言拿來吹噓的資本,下文我們將對在這幾行語句下 Golang 的併發機制和實現進行詳細探索。

一等公民 - Goroutine

Goroutine 是 Go 的併發機制中絕對的主角。它代表了指令流及其執行環境,也是被調度的基本單位。宏觀來看,goroutine 類似操作系統中線程的概念(注意這裏的類比並不嚴格,下文將會對兩者做出詳細比較):不同線程間共享同一個內存空間,但不共享棧且各自併發執行;同樣地,goroutine 也同內存不同棧,併發運行。

如上圖所示,上文代碼片段第四行的 go Hello()會創建一個新的 goroutine(綠色線條),並開始執行 Hello()函數。需要注意的是,由於主 goroutine(藍色線條)和新創建的 goroutine 擁有併發性,且主 goroutine 在執行 go Hello()時並不會等待被調用函數執行結束,故 “I'm A”(主 goroutine 輸出)和 “I'm B”(新 goroutine 輸出)可能以任何順序交錯展現。

爲何不用線程 (pThread)?

直到現在,我們並不能從 goroutine 中看到任何有別於 thread、從而促成 Golang 編寫者拋棄傳統的線程模型自己造輪子的地方。那麼操作系統層面的線程 (pThread) 有什麼問題呢?

生命週期開銷太高

線程的創建、銷燬和切換都需要一系列系統調用,而每一個系統調用意味着觸發軟中斷、進入內核態、將寄存器的值全部存入內存、維護相關數據結構、恢復寄存器、返回用戶態等一系列組合拳。這一輪操作不僅十分耗時、還可能讓內存緩存的加速效果大幅度下滑。所以,避免頻繁創建、銷燬線程作爲高性能併發的必要條件這一點已成爲程序員的共識。

以線程爲併發模型的 C/C++/Java 採用線程池的方法來降低線程昂貴的生命週期開銷。既然線程創建 / 死亡代價高昂,我們何不讓創建的線程永不死亡呢?具體來說,對於每個已經創建但已經完成工作的線程,我們令其休眠,並放進一個資源池中,在下次需要新的線程的時候,我們直接將線程池中休眠的線程拿出來喚醒使用而非新建線程。這樣一來,絕大部分的線程創建 / 銷燬需求都成功地被線程池吸收了。進一步,通過規定線程池的最大容量,我們可以將花費在線程創建和銷燬上的開銷控制在固定值,例如,常見的 Java Web 應用會設立一個 30~50 大小的線程池來處理 HTTP 請求,並取得非常好的併發效果。

不必要的線程切換

即使線程池很好地砍掉了線程生命週期開銷,操作系統層面的線程依然存在不足:線程的語義在於並行,當線程數超出 CPU 核心數時,操作系統會定時給每個 CPU 核心切換不同的線程,讓他們 “看上去” 是同時在進行的。當然,這樣的切換同樣需要付出若干中斷、系統調用,以及當前線程的工作集從緩存中被新線程完全抹去的代價。

乍一聽上去這樣的代價是必不可少的,實則不然。由於在絕大部分時候我們的應用都是 I/O 和計算混合的,即,一段時間與硬盤 / 網絡交互(I/O)、一段時間進行相對密集的內存訪問和計算,而等待 I/O 完成期間該線程處於休眠狀態,CPU 已經會切換到其他線程,即使操作系統不強行打斷並切換處於計算密集期的線程,應用在宏觀上依然顯示出一定併發性。而通過去掉計算密集期的線程切換,整體 CPU 效率得到了有效提升——NodeJS 就是在這樣的哲學下誕生的:單一線程、全異步的 I/O、事件驅動、非搶佔式調度(當某一個函數單純進行計算和內存訪問時不會被打斷),在進行 I/O 密集型工作(如網站後臺)時通過將單一 CPU 利用率逼到 100% 的方式在效率上力挫幾乎其他所有能利用多線程多核腳本語言。這簡直是本來就特立獨行的 Javascript 對整個編程語言界的同僚豎起的又一根中指。當然了,僅僅能利用單核處理能力的 NodeJS 在處理對計算要求更高的工作上顯然會力不從心,但其給我們的啓示值得注意。

較高的切換開銷

在鎖競爭、協程同步等情況下,頻繁進入內核態的線程模型會放大自身在切換開銷上的劣勢。而用戶態的調度器(如 goroutine 調度器)則可以在用戶態處理這一切,省時省力。另外,由於編程語言能夠更好地對自己語言中的同步原語進行分析,編程語言自己的調度器能夠更好地根據語義對調度進行優化。

Goroutine 調度模型

Go 使用用戶態的調度器對 goroutine 的執行進行控制,從而避免了大部分內核開銷。具體而言,Golang 的調度模型由三部分組成:執行環境 (Executor)調度器 (Scheduler) goroutine

執行環境,顧名思義,用來執行代碼。儘管其在抽象概念上應該對應一個 CPU 核心,但由於在用戶態不能接觸硬件資源,故 Go 將其具體實現爲線程。當線程數等於 CPU 核心數時,既最大化了 CPU 核心利用率,又最小化了線程切換的開銷,是最理想的情況(當然,實際情況下操作系統還會運行、切換來自其他進程的線程,但這已經超出一個普通程序的控制範疇)。故默認情況下,用於指定執行環境個數的運行時變量 GOMAXPROCS等於 CPU 核心數目。當然,開發者可以根據自己的需求更改該值,當 GOMAXPROCS=1時,Go 的執行模型幾乎等同於 NodeJS。

調度器則是調度模型的核心,它決定了每個執行環境(核)在什麼時候執行什麼樣的 goroutine。Go 採用任務隊列的方式對 goroutine 進行調度:

如上圖所示,所有 goroutine 作爲任務排在任務隊列中,而 scheduler 所做的則是在 executor 空閒時從隊首拿出下一個 goroutine 給其執行。每個任務 (goroutine) 會被 executor 執行到完成或阻塞(如發起 I/O 請求、系統調用、請求一個正在被其他人使用的鎖或自行 yield 計算資源等),在第二種情況下,該 goroutine 既不在 executor 也不在隊列中,而是處於阻塞態被 Scheduler 監視直到阻塞結束重新入隊。值得注意的是,這裏與上文提到的 “去掉計算密集期的線程切換” 的聯繫:由於調度器對任務採用非搶佔式調度,即在正常計算和內存訪問的情況下 executor 不會放棄當前 goroutine,故多餘的 goroutine 切換代價得以被去除。

這樣的任務隊列模型仍然存在不小的問題:由於任務隊列只有一個,爲了保證出入隊的原子性,任務分配 / 加入時需要對整個隊列加互斥鎖,當 goroutine 執行時間短時,頻繁給大量 executor 分配新任務會讓單一隊列成爲並行的性能瓶頸。爲了解決該問題,Go 採用了多任務隊列的方式進行任務調度:

如上圖所示,在多任務調度模型中,每個 executor 均有一個自己對應的任務隊列。在正常情況下,每個 executor 從自己的隊列中拿 goroutine,並將生成的新 goroutine 放進自己隊列隊尾。分佈式結構可能帶來的問題是顯而易見的:如果任務在隊列的分佈不均勻會導致計算資源的浪費,如上圖中的 executor3,如果缺乏其他措施,該核會因爲對應隊列沒有任務而空閒。對於該問題,Go 的解決方法是引入 “偷任務” 機制:當 Scheduler 發現某隊列無任務可用時,會從其他隊列裏 “偷” 一部分任務過來。由於偷任務的代價較高(需要鎖兩個隊列),Scheduler 會爭取一次性偷足夠多的任務以降低未來偷任務的頻率。

而對於處於阻塞狀態的 goroutine,Scheduler 需要監視其脫離阻塞狀態並重新入隊。Goroutine 被阻塞的原因大體分兩種:

以上便是 Golang Scheduler 的大致工作邏輯,在各個組件的相互配合下,一個高性能、支持調度成千上萬 goroutine 的併發環境就此搭建起來。

總結和啓發

從 Golang 的併發機制中我們可以得到如下幾點啓發:

可以說,Golang 的併發機制是 NodeJS 的普適版,擁有能夠更好利用多核計算力的優勢;和 採用 OS 線程、阻塞 I/O、GIL 的 Python 併發模式 相比則更是雲泥之別。正是更爲精巧的併發機制和簡單的併發原語,使得 Concurrency 成爲 Go 語言最大的賣點。

需要指出的是,Go 所採用的一切技術都並非原創—— go func()的同步原語與 Cilk 十分類似,分佈式任務隊列也多少有模仿 Cilk/OpenMP 的意味,如果非要說不同之處,大概在於 Go 是一個原生支持該功能的完整編程語言,而另外兩者只是 C/C++ 的語法擴展插件吧。..

轉自:

levy.at/blog/24

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/6D4jklEC3mzDdatu4v9-aA