聊這個話題之前,先梳理下兩個概念,幾乎所有講併發的文章都要先講這兩個概念:
-
併發(concurrency) 併發的關注點在於任務切分。舉例來說,你是一個創業公司的CEO,開始只有你一個人,你一人分飾多角,一會做產品規劃,一會寫代碼,一會見客戶,雖然你不能見客戶的同時寫代碼,但由於你切分了任務,分配了時間片,表現出來好像是多個任務一起在執行。
-
並行(parallelism) 並行的關注點在於同時執行。還是上面的例子,你發現你自己太忙了,時間分配不過來,於是請了工程師,產品經理,市場總監,各司一職,這時候多個任務可以同時執行了。
所以總結下,併發並不要求必須並行,可以用時間片切分的方式模擬,比如單核 CPU 上的多任務系統,併發的要求是任務能切分成獨立執行的片段。而並行關注的是同時執行,必須是多(核)CPU,要能並行的程序必須是支持併發的。本文大多數情況下不會嚴格區分這兩個概念,默認併發就是指並行機制下的併發。
爲什麼併發程序這麼難?
We believe that writing correct concurrent, **fault-tolerant **and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction. —— Akka
Akka 官方文檔開篇這句話說的好,之所以寫正確的併發,容錯,可擴展的程序如此之難,是因爲我們用了錯誤的工具和錯誤的抽象。(當然該文檔本來的意思是 Akka 是正確的工具,但我們可以獨立的看待這句話)。
那我們從最開始梳理下程序的抽象。開始我們的程序是面向過程的,數據結構 + func。後來有了面向對象,對象組合了數結構和 func,我們想用模擬現實世界的方式,抽象出對象,有狀態和行爲。但無論是面向過程的 func 還是面向對象的 func,本質上都是代碼塊的組織單元,本身並沒有包含代碼塊的併發策略的定義。於是爲了解決併發的需求,引入了 Thread(線程)的概念。
線程(Thread)
-
系統內核態,更輕量的進程
-
由系統內核進行調度
-
同一進程的多個線程可共享資源
線程的出現解決了兩個問題,一個是 GUI 出現後急切需要併發機制來保證用戶界面的響應。第二是互聯網發展後帶來的多用戶問題。最早的 CGI 程序很簡單,將通過腳本將原來單機版的程序包裝在一個進程裏,來一個用戶就啓動一個進程。但明顯這樣承載不了多少用戶,並且如果進程間需要共享資源還得通過進程間的通信機制,線程的出現緩解了這個問題。
線程的使用比較簡單,如果你覺得這塊代碼需要併發,就把它放在單獨的線程裏執行,由系統負責調度,具體什麼時候使用線程,要用多少個線程,由調用方決定,但定義方並不清楚調用方會如何使用自己的代碼,很多併發問題都是因爲誤用導致的,比如 Go 中的 map 以及 Java 的 HashMap 都不是併發安全的,誤用在多線程環境就會導致問題。另外也帶來複雜度:
-
競態條件(race conditions) 如果每個任務都是獨立的,不需要共享任何資源,那線程也就非常簡單。但世界往往是複雜的,總有一些資源需要共享,比如前面的例子,開發人員和市場人員同時需要和 CEO 商量一個方案,這時候 CEO 就成了競態條件。
-
依賴關係以及執行順序 如果線程之間的任務有依賴關係,需要等待以及通知機制來進行協調。比如前面的例子,如果產品和 CEO 討論的方案依賴於市場和 CEO 討論的方案,這時候就需要協調機制保證順序。
爲了解決上述問題,我們引入了許多複雜機制來保證:
-
Mutex(Lock)(Go 裏的 sync 包, Java 的 concurrent 包)通過互斥量來保護數據,但有了鎖,明顯就降低了併發度。
-
Semaphore 通過信號量來控制併發度或者作爲線程間信號(signal)通知。
-
Volatile Java 專門引入了 volatile 關鍵詞來,來降低只讀情況下的鎖的使用。
-
Compare-and-swap 通過硬件提供的 CAS 機制保證原子性(atomic),也是降低鎖的成本的機制。
如果說上面兩個問題只是增加了複雜度,我們通過深入學習,嚴謹的 Code Review,全面的併發測試(比如 Go 語言中單元測試的時候加上 -race 參數),一定程度上能解決(當然這個也是有爭議的,有論文認爲當前的大多數併發程序沒出問題只是併發度不夠,如果 CPU 核數繼續增加,程序運行的時間更長,很難保證不出問題)。但最讓人頭痛的還是下面這個問題:
系統裏到底需要多少線程?
這個問題我們先從硬件資源入手,考慮下線程的成本:
-
內存(線程的棧空間)
每個線程都需要一個棧(Stack)空間來保存掛起(suspending)時的狀態。Java 的棧空間(64位VM)默認是 1024k,不算別的內存,只是棧空間,啓動 1024 個線程就要 1G 內存。雖然可以用 -Xss 參數控制,但由於線程是本質上也是進程,系統假定是要長期運行的,棧空間太小會導致稍複雜的遞歸調用(比如複雜點的正則表達式匹配)導致棧溢出。所以調整參數治標不治本。
-
調度成本(context-switch)
我在個人電腦上做的一個非嚴格測試,模擬兩個線程互相喚醒輪流掛起,線程切換成本大約 6000 納秒/次。這個還沒考慮棧空間大小的影響。國外一篇論文專門分析線程切換的成本,基本上得出的結論是切換成本和棧空間使用大小直接相關。
-
CPU使用率
我們搞併發最主要的一個目標就是我們有了多核,想提高CPU利用率,最大限度的壓榨硬件資源,從這個角度考慮,我們應該用多少線程呢?
這個我們可以通過一個公式計算出來,100 / (15 + 5) * 4 = 20,用 20 個線程最合適。但一方面網絡的時間不是固定的,另外一方面,如果考慮到其他瓶頸資源呢?比如鎖,比如數據庫連接池,就會更復雜。
作爲一個 1 歲多孩子的父親,認爲這個問題的難度好比你要寫個給孩子餵飯的程序,需要考慮『給孩子喂多少飯合適?』,這個問題有以下回答以及策略:
-
孩子不吃了就好了(但孩子貪玩,不吃了可能是想去玩了)
-
孩子吃飽了就好了(廢話,你怎麼知道孩子吃飽了?孩子又不會說話)
-
逐漸增量,長期觀察,然後計算一個平均值(這可能是我們調整線程常用的策略,但增量增加到多少合適呢?)
-
孩子吃吐了就別餵了(如果用逐漸增量的模式,通過外部觀察,可能會到達這個邊界條件。系統性能如果因爲線程的增加倒退了,就別增加線程了)
-
沒控制好邊界,把孩子給給撐壞了 (這熊爸爸也太恐怖了。但調整線程的時候往往不小心可能就把系統搞掛了)
通過這個例子我們可以看出,從外部系統來觀察,或者以經驗的方式進行計算,都是非常困難的。於是結論是:
讓孩子會說話,吃飽了自己說,自己學會吃飯,自管理是最佳方案。
然並卵,計算機不會自己說話,如何自管理?
但我們從以上的討論可以得出一個結論:
-
線程的成本較高(內存,調度)不可能大規模創建
-
應該由語言或者框架動態解決這個問題
線程池方案
Java 1.5 後,Doug Lea 的 Executor 系列被包含在默認的 JDK 內,是典型的線程池方案。
線程池一定程度上控制了線程的數量,實現了線程複用,降低了線程的使用成本。但還是沒有解決數量的問題,線程池初始化的時候還是要設置一個最小和最大線程數,以及任務隊列的長度,自管理只是在設定範圍內的動態調整。另外不同的任務可能有不同的併發需求,爲了避免互相影響可能需要多個線程池,最後導致的結果就是 Java 的系統裏充斥了大量的線程池。
新的思路
從前面的分析我們可以看出,如果線程是一直處於運行狀態,我們只需設置和 CPU 核數相等的線程數即可,這樣就可以最大化的利用 CPU,並且降低切換成本以及內存使用。但如何做到這一點呢?
陳力就列,不能者止
這句話是說,能幹活的代碼片段就放在線程裏,如果幹不了活(需要等待,被阻塞等),就摘下來。通俗的說就是不要佔着茅坑不拉屎,如果拉不出來,需要醞釀下,先把茅坑讓出來,因爲茅坑是稀缺資源。
要做到這點一般有兩種方案:
-
異步回調方案 典型如 NodeJS,遇到阻塞的情況,比如網絡調用,則註冊一個回調方法(其實還包括了一些上下文數據對象)給 IO 調度器(Linux 下是 Libev,調度器在另外的線程裏),當前線程就被釋放了,去幹別的事情了。等數據準備好,調度器會將結果傳遞給回調方法然後執行,執行其實不在原來發起請求的線程裏了,但對用戶來說無感知。但這種方式的問題就是很容易遇到 callback hell,因爲所有的阻塞操作都必須異步,否則系統就卡死了。還有就是異步的方式有點違反人類思維習慣,人類還是習慣同步的方式。
-
GreenThread/Coroutine/Fiber 方案 這種方案其實和上面的方案本質上區別不大,關鍵在於回調上下文的保存以及執行機制。爲了解決回調方法帶來的難題,這種方案的思路是寫代碼的時候還是按順序寫,但遇到 IO 等阻塞調用時,將當前的代碼片段暫停,保存上下文,讓出當前線程。等 IO 事件回來,然後再找個線程讓當前代碼片段恢復上下文繼續執行,寫代碼的時候感覺好像是同步的,彷彿在同一個線程完成的,但實際上系統可能切換了線程,但對程序無感。
GreenThread
-
用戶空間 首先是在用戶空間,避免內核態和用戶態的切換導致的成本。
-
由語言或者框架層調度
-
更小的棧空間允許創建大量實例(百萬級別)
幾個概念
-
Continuation 這個概念不熟悉 FP 編程的人可能不太熟悉,不過這裏可以簡單的顧名思義,可以理解爲讓我們的程序可以暫停,然後下次調用繼續(contine)從上次暫停的地方開始的一種機制。相當於程序調用多了一種入口。
-
Coroutine 是 Continuation 的一種實現,一般表現爲語言層面的組件或者類庫。主要提供 yield,resume 機制。
-
Fiber 和 Coroutine 其實是一體兩面的,主要是從系統層面描述,可以理解成 Coroutine 運行之後的東西就是 Fiber。
Goroutine
Goroutine 其實就是前面 GreenThread 系列解決方案的一種演進和實現。
-
首先,它內置了 Coroutine 機制。因爲要用戶態的調度,必須有可以讓代碼片段可以暫停/繼續的機制。
-
其次,它內置了一個調度器,實現了 Coroutine 的多線程並行調度,同時通過對網絡等庫的封裝,對用戶屏蔽了調度細節。
-
最後,提供了 Channel 機制,用於 Goroutine 之間通信,實現 CSP 併發模型(Communicating Sequential Processes)。因爲 Go 的 Channel 是通過語法關鍵詞提供的,對用戶屏蔽了許多細節。其實 Go 的 Channel 和 Java 中的 SynchronousQueue 是一樣的機制,如果有 buffer 其實就是 ArrayBlockQueue。
Goroutine 調度器
這個圖一般講 Goroutine 調度器的地方都會引用,想要仔細瞭解的可以看看原博客(小編:點擊閱讀原文獲取)。這裏只說明幾點:
-
M 代表系統線程,P 代表處理器(核),G 代表 Goroutine。Go 實現了 M : N 的調度,也就是說線程和 Goroutine 之間是多對多的關係。這點在許多GreenThread / Coroutine 的調度器並沒有實現。比如 Java 1.1 版本之前的線程其實是 GreenThread(這個詞就來源於 Java),但由於沒實現多對多的調度,也就是沒有真正實現並行,發揮不了多核的優勢,所以後來改成基於系統內核的 Thread 實現了。
-
某個系統線程如果被阻塞,排列在該線程上的 Goroutine 會被遷移。當然還有其他機制,比如 M 空閒了,如果全局隊列沒有任務,可能會從其他 M 偷任務執行,相當於一種 rebalance 機制。這裏不再細說,有需要看專門的分析文章。
-
具體的實現策略和我們前面分析的機制類似。系統啓動時,會啓動一個獨立的後臺線程(不在 Goroutine 的調度線程池裏),啓動 netpoll 的輪詢。當有 Goroutine 發起網絡請求時,網絡庫會將 fd(文件描述符)和 pollDesc(用於描述 netpoll 的結構體,包含因爲讀 / 寫這個 fd 而阻塞的 Goroutine)關聯起來,然後調用 runtime.gopark 方法,掛起當前的 Goroutine。當後臺的 netpoll 輪詢獲取到 epoll(Linux 環境下)的 event,會將 event 中的 pollDesc 取出來,找到關聯的阻塞 Goroutine,並進行恢復。
Goroutine 是銀彈麼?
Goroutine 很大程度上降低了併發的開發成本,是不是我們所有需要併發的地方直接 go func 就搞定了呢?
Go 通過 Goroutine 的調度解決了 CPU 利用率的問題。但遇到其他的瓶頸資源如何處理?比如帶鎖的共享資源,比如數據庫連接等。互聯網在線應用場景下,如果每個請求都扔到一個 Goroutine 裏,當資源出現瓶頸的時候,會導致大量的 Goroutine 阻塞,最後用戶請求超時。這時候就需要用 Goroutine 池來進行控流,同時問題又來了:池子裏設置多少個 Goroutine 合適?
所以這個問題還是沒有從更本上解決。
Actor 模型
Actor 對沒接觸過這個概念的人可能不太好理解,Actor 的概念其實和 OO 裏的對象類似,是一種抽象。面對對象編程對現實的抽象是對象 = 屬性 + 行爲(method),但當使用方調用對象行爲(method)的時候,其實佔用的是調用方的 CPU 時間片,是否併發也是由調用方決定的。這個抽象其實和現實世界是有差異的。現實世界更像 Actor 的抽象,互相都是通過異步消息通信的。比如你對一個美女 say hi,美女是否迴應,如何迴應是由美女自己決定的,運行在美女自己的大腦裏,並不會佔用發送者的大腦。
所以 Actor 有以下特徵:
-
Processing – actor 可以做計算的,不需要佔用調用方的 CPU 時間片,併發策略也是由自己決定。
-
Storage – actor 可以保存狀態
-
Communication – actor 之間可以通過發送消息通訊
Actor 遵循以下規則:
-
發送消息給其他的 Actor
-
創建其他的 Actor
-
接受並處理消息,修改自己的狀態
Actor 的目標:
-
Actor 可獨立更新,實現熱升級。因爲 Actor 互相之間沒有直接的耦合,是相對獨立的實體,可能實現熱升級。
-
無縫彌合本地和遠程調用 因爲 Actor 使用基於消息的通訊機制,無論是和本地的 Actor,還是遠程 Actor 交互,都是通過消息,這樣就彌合了本地和遠程的差異。
-
容錯 Actor 之間的通信是異步的,發送方只管發送,不關心超時以及錯誤,這些都由框架層和獨立的錯誤處理機制接管。
-
易擴展,天然分佈式 因爲 Actor 的通信機制彌合了本地和遠程調用,本地Actor 處理不過來的時候,可以在遠程節點上啓動 Actor 然後轉發消息過去。
Actor 的實現:
-
Erlang/OTP Actor 模型的標杆,其他的實現基本上都一定程度參照了 Erlang 的模式。實現了熱升級以及分佈式。
-
Akka(Scala,Java)基於線程和異步回調模式實現。由於 Java 中沒有 Fiber,所以是基於線程的。爲了避免線程被阻塞,Akka 中所有的阻塞操作都需要異步化。要麼是 Akka 提供的異步框架,要麼通過 Future-callback 機制,轉換成回調模式。實現了分佈式,但還不支持熱升級。
-
Quasar (Java) 爲了解決 Akka 的阻塞回調問題,Quasar 通過字節碼增強的方式,在 Java 中實現了 Coroutine/Fiber。同時通過 ClassLoader 的機制實現了熱升級。缺點是系統啓動的時候要通過 javaagent 機制進行字節碼增強。
Golang CSP VS Actor
二者的格言都是:
Don’t communicate by sharing memory, share memory by communicating
通過消息通信的機制來避免競態條件,但具體的抽象和實現上有些差異。
-
CSP 模型裏消息和 Channel 是主體,處理器是匿名的。
也就是說發送方需要關心自己的消息類型以及應該寫到哪個 Channel,但不需要關心誰消費了它,以及有多少個消費者。Channel 一般都是類型綁定的,一個 Channel 只寫同一種類型的消息,所以 CSP 需要支持 alt/select 機制,同時監聽多個 Channel。Channel 是同步的模式(Golang 的 Channel 支持 buffer,支持一定數量的異步),背後的邏輯是發送方非常關心消息是否被處理,CSP 要保證每個消息都被正常處理了,沒被處理就阻塞着。
-
Actor 模型裏 Actor 是主體,Mailbox(類似於 CSP 的 Channel)是透明的。
也就是說它假定發送方會關心消息發給誰消費了,但不關心消息類型以及通道。所以 Mailbox 是異步模式,發送者不能假定發送的消息一定被收到和處理。Actor 模型必須支持強大的模式匹配機制,因爲無論什麼類型的消息都會通過同一個通道發送過來,需要通過模式匹配機制做分發。它背後的邏輯是現實世界本來就是異步的,不確定(non-deterministic)的,所以程序也要適應面對不確定的機制編程。自從有了並行之後,原來的確定編程思維模式已經受到了挑戰,而 Actor 直接在模式中蘊含了這點。
從這樣看來,CSP 的模式比較適合 Boss-Worker 模式的任務分發機制,它的侵入性沒那麼強,可以在現有的系統中通過 CSP 解決某個具體的問題。它並不試圖解決通信的超時容錯問題,這個還是需要發起方進行處理。同時由於 Channel 是顯式的,雖然可以通過 netchan(原來 Go 提供的 netchan 機制由於過於複雜,被廢棄,在討論新的 netchan)實現遠程 Channel,但很難做到對使用方透明。而 Actor 則是一種全新的抽象,使用 Actor 要面臨整個應用架構機制和思維方式的變更。它試圖要解決的問題要更廣一些,比如容錯,比如分佈式。但Actor的問題在於以當前的調度效率,哪怕是用 Goroutine 這樣的機制,也很難達到直接方法調用的效率。當前要像 OO 的『一切皆對象』一樣實現一個『一切皆 Actor』的語言,效率上肯定有問題。所以折中的方式是在 OO 的基礎上,將系統的某個層面的組件抽象爲 Actor。
再扯一下 Rust
Rust 解決併發問題的思路是首先承認現實世界的資源總是有限的,想徹底避免資源共享是很難的,不試圖完全避免資源共享,它認爲併發的問題不在於資源共享,而在於錯誤的使用資源共享。比如我們前面提到的,大多數語言定義類型的時候,並不能限制調用方如何使用,只能通過文檔或者標記的方式(比如 Java 中的 @ThreadSafe, @NotThreadSafe annotation)說明是否併發安全,但也只能僅僅做到提示的作用,不能阻止調用方誤用。雖然 Go 提供了 -race 機制,可以通過運行單元測試的時候帶上這個參數來檢測競態條件,但如果你的單元測試併發度不夠,覆蓋面不到也檢測不出來。所以 Rust 的解決方案就是:
-
定義類型的時候要明確指定該類型是否是併發安全的
-
引入了變量的所有權(Ownership)概念 非併發安全的數據結構在多個線程間轉移,也不一定就會導致問題,導致問題的是多個線程同時操作,也就是說是因爲這個變量的所有權不明確導致的。有了所有權的概念後,變量只能由擁有所有權的作用域代碼操作,而變量傳遞會導致所有權變更,從語言層面限制了競態條件出現的情況。
有了這機制,Rust 可以在編譯期而不是運行期對競態條件做檢查和限制。雖然開發的時候增加了心智成本,但降低了調用方以及排查併發問題的心智成本,也是一種有特色的解決方案。
結論
革命尚未成功 同志任需努力
本文帶大家一起回顧了併發的問題,和各種解決方案。雖然各家有各家的優勢以及使用場景,但併發帶來的問題還遠遠沒到解決的程度。所以還需努力,大家也有機會。
最後拋個磚,構想:在 Goroutine 上實現 Actor?
-
分佈式 解決了單機效率問題,是不是可以嘗試解決下分佈式效率問題?
-
和容器集羣融合 當前的自動伸縮方案基本上都是通過監控服務器或者 LoadBalancer,設置一個閥值來實現的。類似於我前面提到的餵飯的例子,是基於經驗的方案,但如果系統內和外部集羣結合,這個事情就可以做的更細緻和智能。
-
自管理 前面的兩點最終的目標都是實現一個可以自管理的系統。做過系統運維的同學都知道,我們照顧系統就像照顧孩子一樣,時刻要監控系統的各種狀態,接受系統的各種報警,然後排查問題,進行緊急處理。孩子有長大的一天,那能不能讓系統也自己成長,做到自管理呢?雖然這個目標現在看來還比較遠,但我覺得是可以期待的。
引用以及擴展閱讀
- 本文的演講視頻
- 本文的演講pdf
- CSP model paper
- Actor model paper
- Quantifying The Cost of Context Switch
- JCSP 在Java中實現CSP模型的庫
- Overview of Modern Concurrency and Parallelism Concepts
- Golang netchan 的討論
- quasar vs akka
- golang 官方博客的 concurrency is not parallelism
- go scheduler, 文中的調度器圖片來源
- handling-1-million-requests-per-minute-with-golang 一個用Goroutine的控流實踐
(頭圖作者: Sameer Ajmani)