學習Java多年 卻回答不出面試官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 函數調用會帶來額外的開銷。
好了今天就先說到這裏
大家看完有什麼不懂的可以在下方留言討論也可以關注.
謝謝你的觀看。
覺得文章對你有幫助的話記得關注我點個贊支持一下!



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章