一文詳解 Java 並發模型

程序員cxuan 發佈 2020-08-13T09:57:35+00:00

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

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

可以使用不同的並發模型來實現並發系統,並發模型說的是系統中的線程如何協作完成並發任務。不同的並發模型以不同的方式拆分任務,線程可以以不同的方式進行通信和協作。

並發模型和分布式系統很相似

並發模型其實和分布式系統模型非常相似,在並發模型中是線程彼此進行通信,而在分布式系統模型中是 進程 彼此進行通信。然而本質上,進程和線程也非常相似。這也就是為什麼並發模型和分布式模型非常相似的原因。

分布式系統通常要比並發系統面臨更多的挑戰和問題比如進程通信、網絡可能出現異常,或者遠程機器掛掉等等。但是一個並發模型同樣面臨著比如 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 領取優質資料。

關鍵字: