一網打盡 Java 併發模型

本篇文章我們來探討一下併發設計模型。

可以使用不同的併發模型來實現併發系統，併發模型說的是系統中的執行緒如何共同作業完成併發任務。不同的併發模型以不同的方式拆分任務，執行緒可以以不同的方式進行通訊和共同作業。

併發模型和分佈式系統很相似

併發模型其實和分佈式系統模型非常相似，在併發模型中是執行緒彼此進行通訊，而在分佈式系統模型中是 進程 彼此進行通訊。然而本質上，進程和執行緒也非常相似。這也就是爲什麼併發模型和分佈式模型非常相似的原因。

分佈式系統通常要比並發系統面臨更多的挑戰和問題比如進程通訊、網路可能出現異常，或者遠端機器掛掉等等。但是一個併發模型同樣面臨着比如 CPU 故障、網絡卡出現問題、硬碟出現問題等。

因爲併發模型和分佈式模型很相似，因此他們可以相互借鑑，例如用於執行緒分配的模型就類似於分佈式系統環境中的負載均衡模型。

其實說白了，分佈式模型的思想就是借鑑併發模型的基礎上推演發展來的。

認識兩個狀態

併發模型的一個重要的方面是，執行緒是否應該共用狀態，是具有共用狀態還是獨立狀態。共用狀態也就意味着在不同線程之間共用某些狀態

狀態其實就是數據，比如一個或者多個物件。當執行緒要共用數據時，就會造成 競態條件 或者 死鎖 等問題。當然，這些問題只是可能會出現，具體實現方式取決於你是否安全的使用和存取共用物件。

獨立的狀態表明狀態不會在多個執行緒之間共用，如果執行緒之間需要通訊的話，他們可以存取不可變的物件來實現，這是一種最有效的避免併發問題的一種方式，如下圖所示

使用獨立狀態讓我們的設計更加簡單，因爲只有一個執行緒能夠存取物件，即使交換物件，也是不可變的物件。

併發模型

並行 Worker

第一個併發模型是並行 worker 模型，用戶端會把任務交給 代理人(Delegator)，然後由代理人把工作分配給不同的 工人(worker)。如下圖所示

並行 worker 的核心思想是，它主要有兩個進程即代理人和工人，Delegator 負責接收來自用戶端的任務並把任務下發，交給具體的 Worker 進行處理，Worker 處理完成後把結果返回給 Delegator，在 Delegator 接收到 Worker 處理的結果後對其進行彙總，然後交給用戶端。

並行 Worker 模型是 Java 併發模型中非常常見的一種模型。許多 java.util.concurrent 包下的併發工具都使用了這種模型。

並行 Worker 的優點

並行 Worker 模型的一個非常明顯的特點就是很容易理解，爲了提高系統的並行度你可以增加多個 Worker 完成任務。

並行 Worker 模型的另外一個好處就是，它會將一個任務拆分成多個小任務，併發執行，Delegator 在接受到 Worker 的處理結果後就會返回給 Client，整個 Worker -> Delegator -> Client 的過程是非同步的。

並行 Worker 的缺點

同樣的，並行 Worker 模式同樣會有一些隱藏的缺點

共用狀態會變得很複雜

實際的並行 Worker 要比我們圖中畫出的更復雜，主要是並行 Worker 通常會存取記憶體或共用數據庫中的某些共用數據。

這些共用狀態可能會使用一些工作佇列來儲存業務數據、數據快取、數據庫的連線池等。線上程通訊中，執行緒需要確保共用狀態是否能夠讓其他執行緒共用，而不是僅僅停留在 CPU 快取中讓自己可用，當然這些都是程式設計師在設計時就需要考慮的問題。執行緒需要避免 競態條件，死鎖 和許多其他共用狀態造成的併發問題。

多執行緒在存取共用數據時，會丟失併發性，因爲操作系統要保證只有一個執行緒能夠存取數據，這會導致共用數據的爭用和搶佔。未搶佔到資源的執行緒會 阻塞。

現代的非阻塞併發演算法可以減少爭用提高效能，但是非阻塞演算法比較難以實現。

可持久化的數據結構(Persistent data structures) 是另外一個選擇。可持久化的數據結構在修改後始終會保留先前版本。因此，如果多個執行緒同時修改一個可持久化的數據結構，並且一個執行緒對其進行了修改，則修改的執行緒會獲得對新數據結構的參照。

雖然可持久化的數據結構是一個新的解決方法，但是這種方法實行起來卻有一些問題，比如，一個持久列表會將新元素新增到列表的開頭，並返回所新增的新元素的參照，但是其他執行緒仍然只持有列表中先前的第一個元素的參照，他們看不到新新增的元素。

持久化的數據結構比如 鏈表(LinkedList) 在硬體效能上表現不佳。列表中的每個元素都是一個物件，這些物件散佈在計算機記憶體中。現代 CPU 的順序存取往往要快的多，因此使用陣列等順序存取的數據結構則能夠獲得更高的效能。CPU 快取記憶體可以將一個大的矩陣塊載入到快取記憶體中，並讓 CPU 在載入後直接存取 CPU 快取記憶體中的數據。對於鏈表，將元素分散在整個 RAM 上，這實際上是不可能的。

無狀態的 worker

共用狀態可以由其他執行緒所修改，因此，worker 必須在每次操作共用狀態時重新讀取，以確保在副本上能夠正確工作。不線上程內部保持狀態的 worker 成爲無狀態的 worker。

作業順序是不確定的

並行工作模型的另一個缺點是作業的順序不確定，無法保證首先執行或最後執行哪些作業。任務 A 在任務 B 之前分配給 worker，但是任務 B 可能在任務 A 之前執行。

流水線

第二種併發模型就是我們經常在生產車間遇到的 流水線併發模型，下面 下麪是流水線設計模型的流程圖

這種組織架構就像是工廠中裝配線中的 worker，每個 worker 只完成全部工作的一部分，完成一部分後，worker 會將工作轉發給下一個 worker。

每道程式都在自己的執行緒中執行，彼此之間不會共用狀態，這種模型也被稱爲無共用併發模型。

使用流水線併發模型通常被設計爲非阻塞I/O，也就是說，當沒有給 worker 分配任務時，worker 會做其他工作。非阻塞I/O 意味着當 worker 開始 I/O 操作，例如從網路中讀取檔案，worker 不會等待 I/O 呼叫完成。因爲 I/O 操作很慢，所以等待 I/O 非常耗費時間。在等待 I/O 的同時，CPU 可以做其他事情，I/O 操作完成後的結果將傳遞給下一個 worker。下面 下麪是非阻塞 I/O 的流程圖

在實際情況中，任務通常不會按着一條裝配線流動，由於大多數程式需要做很多事情，因此需要根據完成的不同工作在不同的 worker 之間流動，如下圖所示

任務還可能需要多個 worker 共同參與完成

響應式 - 事件驅動系統

使用流水線模型的系統有時也被稱爲 響應式 或者 事件驅動系統，這種模型會根據外部的事件作出響應，事件可能是某個 HTTP 請求或者某個檔案完成載入到記憶體中。

Actor 模型

在 Actor 模型中，每一個 Actor 其實就是一個 Worker， 每一個 Actor 都能夠處理任務。

簡單來說，Actor 模型是一個併發模型，它定義了一系列系統元件應該如何動作和互動的通用規則，最著名的使用這套規則的程式語言是 Erlang。一個參與者Actor對接收到的訊息做出響應，然後可以建立出更多的 Actor 或發送更多的訊息，同時準備接收下一條訊息。

Channels 模型

在 Channel 模型中，worker 通常不會直接通訊，與此相對的，他們通常將事件發送到不同的 通道(Channel)上，然後其他 worker 可以在這些通道上獲取訊息，下面 下麪是 Channel 的模型圖

有的時候 worker 不需要明確知道接下來的 worker 是誰，他們只需要將作者寫入通道中，監聽 Channel 的 worker 可以訂閱或者取消訂閱，這種方式降低了 worker 和 worker 之間的耦合性。

流水線設計的優點

與並行設計模型相比，流水線模型具有一些優勢，具體優勢如下

不會存在共用狀態

因爲流水線設計能夠保證 worker 在處理完成後再傳遞給下一個 worker，所以 worker 與 worker 之間不需要共用任何狀態，也就不用無需考慮以爲併發而引起的併發問題。你甚至可以在實現上把每個 worker 看成是單執行緒的一種。

有狀態 worker

因爲 worker 知道沒有其他執行緒修改自身的數據，所以流水線設計中的 worker 是有狀態的，有狀態的意思是他們可以將需要操作的數據保留在記憶體中，有狀態通常比無狀態更快。

更好的硬體整合

因爲你可以把流水線看成是單執行緒的，而單執行緒的工作優勢在於它能夠和硬體的工作方式相同。因爲有狀態的 worker 通常在 CPU 中快取數據，這樣可以更快地存取快取的數據。

使任務更加有效的進行

可以對流水線併發模型中的任務進行排序，一般用來日誌的寫入和恢復。

流水線設計的缺點

流水線併發模型的缺點是任務會涉及多個 worker，因此可能會分散在專案程式碼的多個類中。因此很難確定每個 worker 都在執行哪個任務。流水線的程式碼編寫也比較困難，設計許多巢狀回撥處理程式的程式碼通常被稱爲 回撥地獄。回撥地獄很難追蹤 debug。

函數性並行

函數性並行模型是最近才提出的一種併發模型，它的基本思路是使用函數呼叫來實現。訊息的傳遞就相當於是函數的呼叫。傳遞給函數的參數都會被拷貝，因此在函數之外的任何實體都無法操縱函數內的數據。這使得函數執行類似於原子操作。每個函數呼叫都可以獨立於任何其他函數呼叫執行。

當每個函數呼叫獨立執行時，每個函數都可以在單獨的 CPU 上執行。這也就是說，函數式並行並行相當於是各個 CPU 單獨執行各自的任務。

JDK 1.7 中的 ForkAndJoinPool 類就實現了函數性並行的功能。Java 8 提出了 stream 的概念，使用並行流也能夠實現大量集合的迭代。

函數性並行的難點是要知道函數的呼叫流程以及哪些 CPU 執行了哪些函數，跨 CPU 函數呼叫會帶來額外的開銷。

你好，我是 cxuan，我自己手寫了四本 PDF，分別是 Java基礎總結、HTTP 核心總結、計算機基礎知識，操作系統核心總結，我已經整理成爲 PDF，可以關注公衆號 Java建設者 回覆 回復 PDF 領取優質資料。