并發(fā)與并行

并發(fā)和并行都可以是相對于進程或是線程來說。并發(fā)是指一個或若干個CPU對多個進程或線程之間進行多路復(fù)用，用簡單的語言來說就是CPU輪著執(zhí)行多個任務(wù)，每個任務(wù)都執(zhí)行一小段時間，從宏觀上看起來就像是全部任務(wù)都在同時執(zhí)行一樣。并行則是指多個進程或線程同一時刻被執(zhí)行，這是真正意義上的同時執(zhí)行，它必須要有多個CPU的支持。

如下圖是并發(fā)和并行的執(zhí)行時間圖。對于并發(fā)來說，線程一線執(zhí)行一段時間，然后線程二再執(zhí)行一段時間，接著線程三再執(zhí)行一段時間。每個線程都輪流得到CPU的執(zhí)行時間，這種情況下只需要一個CPU即能夠?qū)崿F(xiàn)。對于并行來說，線程一、線程二和線程三是同時執(zhí)行的，這種情況下需要三個CPU才能實現(xiàn)。并發(fā)和并行都提升了CPU的資源利用率。

關(guān)于并發(fā)模型

擁有多個CPU的現(xiàn)代計算機依靠并行并發(fā)機制能更快地執(zhí)行任務(wù)，但是如何通過并發(fā)并行來執(zhí)行一個任務(wù)是有很多種不同的方式的，即不同的并發(fā)模型。不同的并發(fā)模型對任務(wù)的拆分可能也不同，此外線程之間的通信方式可能也不同。由于并發(fā)模型規(guī)定了任務(wù)描述、執(zhí)行方式和線程協(xié)作等的總體框架，所以并發(fā)模型的設(shè)計需要考慮的點也有很多，比如如何簡化對任務(wù)的描述、如何讓并發(fā)更高效地執(zhí)行、如何讓開發(fā)人員更方便實現(xiàn)并發(fā)等等。

從進程與線程角度

對于并發(fā)模型，如果我們從進程和線程的角度來看的話， 它主要有三種映射模式：單進程-多線程、多進程-單線程以及多進程-多線程。一般來說，進程的顆粒度大且占用資源多，而線程則是小顆粒且輕量級的。某個程序啟動后就是一個進程，一個進程可以對應(yīng)一個線程，也可以包含若干個線程。下面我們分別來看看進程與線程的三種映射模式。

單進程-多線程

這種映射模式是指一個進程包含了多個線程來執(zhí)行任務(wù)，這是我們最常見的一種模式，特別是對于Java語言來說更是從語言層面天然使用該模式。在Java中寫并發(fā)處理時使用的都是線程概念，我們可以創(chuàng)建多個線程來達到并發(fā)并行效果，Java啟動后就是一個JVM進程，而進程里面就包含了若干線程。一般來說，當線程數(shù)量少于CPU個數(shù)時，操作系統(tǒng)會讓一個CPU對應(yīng)一個線程，這樣就能提高CPU的使用率。此外，由于多個線程共享進程內(nèi)部資源，所以需要考慮線程安全問題。下圖是多個CPU執(zhí)行一個進程，進程包含了四個線程。

多進程-單線程

這種映射模式是指多個進程共同執(zhí)行處理任務(wù)，而每個進程內(nèi)部只有一個線程。也就是程序啟動后主進程會創(chuàng)建出多個子進程，每個子進程對應(yīng)一個線程。這種模式下不存在線程安全問題，因為每個進程之間相互隔離，而內(nèi)部只有一個線程不存在共享內(nèi)存問題。我們知道進程是一個比較重的操作，所以該模式會消耗更多的系統(tǒng)資源，比如內(nèi)存消耗和進程切換CPU消耗。下圖是多個CPU執(zhí)行多個進程，每個進程包含一個線程。

多進程-多線程

這種映射模式結(jié)合了前面兩種模式，多個進程共同執(zhí)行任務(wù)，而且每個進程都包含了多個線程。一個進程最多可以包含的線程數(shù)是有限的，而且當包含的線程數(shù)量太多時可能會導(dǎo)致性能下降，此時就可以引入多個進程來解決，即多進程多線程模式。該模式也需要考慮線程安全問題，涉及到進程切換和線程切換。一般認為該模式可以增加并發(fā)處理能力，特別是對于IO密集型任務(wù)，但由于要更多的上下文切換，所以對于CPU密集型任務(wù)的總體處理能力不一定更優(yōu)。下圖是多個CPU執(zhí)行多個進程，每個進程里面包含多個進程。

無狀態(tài)的并發(fā)并行

為了使用并行并發(fā)機制，我們會將大任務(wù)拆分成很多小任務(wù)，比如對大量數(shù)據(jù)進行累加時可以分為若干個累加任務(wù)來并行并發(fā)處理，又比如web服務(wù)器對客戶端的請求任務(wù)可以分為一個個請求來并行并發(fā)處理。當我們拆分后的任務(wù)不涉及共享狀態(tài)（即無狀態(tài)）時，無狀態(tài)也就代表著多個進程和線程無需訪問共享數(shù)據(jù)，這種情況下的并行并發(fā)就比較簡單，不必考慮線程安全問題。同樣以web服務(wù)器為例，如果我們處理的請求不涉及session時，那么就不涉及共享數(shù)據(jù)問題。下圖上面是并發(fā)執(zhí)行，而下圖則是并行執(zhí)行。

共享狀態(tài)問題

相對于無狀態(tài)，并發(fā)并行時更多的是需要訪問共享數(shù)據(jù)的情況，此時就存在共享狀態(tài)問題。最常見的共享數(shù)據(jù)是保持在內(nèi)存中，當然也可能保存在數(shù)據(jù)庫或其它的存儲系統(tǒng)上。一旦涉及到了共享狀態(tài)，問題就會變得復(fù)雜起來，因為會涉及到競爭條件、死鎖以及其它并發(fā)問題，而且對共享狀態(tài)的不同訪問策略也可能會影響執(zhí)行的結(jié)果。此外，我們前面也學(xué)習過計算機的結(jié)構(gòu)，數(shù)據(jù)從內(nèi)存到CPU中間可能會經(jīng)歷若干高速緩存和寄存器，這就又引出了數(shù)據(jù)可見性問題。由此可以看到共享狀態(tài)的并行并發(fā)需要解決的問題很多，這也正是并發(fā)編程這么復(fù)雜的原因，盡管很多編程語言從語言層面嘗試將問題的復(fù)雜性封裝起來，但并沒有辦法完全解決。下圖是有共享狀態(tài)的并行并發(fā)，上面是并發(fā)過程中多個線程會訪問共享狀態(tài)，而下面是并行過程中多個線程訪問共享狀態(tài)。

并發(fā)模型設(shè)計

前面我們提到過并發(fā)模型需要考慮的主體是CPU和任務(wù)，并發(fā)模型則是規(guī)定了任務(wù)描述、執(zhí)行方式和線程協(xié)作等的總體框架。下面我們從并發(fā)框架設(shè)計的角度來了解幾種常見的并發(fā)模型。

Fork/Join模型

首先先看Fork/Join模型，該模型其實就是一種分治思想，就是將任務(wù)不斷分解成更小的任務(wù)，執(zhí)行完畢后又將小任務(wù)的結(jié)果進行匯總。Fork操作就是分割任務(wù)，而Join操作就是合并結(jié)果。其實如果對常用的數(shù)據(jù)結(jié)構(gòu)和算法比較熟的話應(yīng)該就知道合并排序的做法，它就是使用了類似的思想。

我們看下面的圖，任務(wù)-1是總?cè)蝿?wù)，通過fork操作分割成了任務(wù)-1-1、任務(wù)-1-2、任務(wù)-1-3這三個子任務(wù)。其中任務(wù)1-1又繼續(xù)通過fork操作分割成任務(wù)-1-1-1和任務(wù)-1-1-2，而任務(wù)-1-3則分割成任務(wù)-1-3-1和任務(wù)-1-3-2。任務(wù)-1-1-1和任務(wù)-1-1-2分別進行join操作將子任務(wù)結(jié)果傳給任務(wù)1-1作為其結(jié)果，其它子任務(wù)也類似，一層層網(wǎng)上傳遞，最終匯總作為總?cè)蝿?wù)的最終結(jié)果。

Reactor模型

Reactor模型是一種服務(wù)器端的模型，該模型能夠處理多個客戶端并發(fā)請求訪問，它需要非阻塞機制的支持。Reactor模型將服務(wù)器端的整個處理過程分成若干個事件，例如分為接收事件、讀事件、寫事件、執(zhí)行事件等。接著事件分發(fā)器會檢測事件并將事件分發(fā)給相應(yīng)的處理器去處理。每個處理器只負責自己的事情，而且要讓所有的處理器都不產(chǎn)生阻塞，理想狀態(tài)下每個事件處理器都能充分利用CPU。

如圖所示，若干客戶端連接訪問服務(wù)器端，Reactor的事件分發(fā)器負責檢測事件并將各種事件分發(fā)到對應(yīng)處理器上，這些處理器包括接收連接的accept處理器、讀數(shù)據(jù)的read處理器、寫數(shù)據(jù)的write處理器以及執(zhí)行邏輯的process處理器。在整個過程中只要有待處理的事件存在，即可以讓Reactor線程不斷往下執(zhí)行，而不會阻塞在某處，所以處理效率很高。

Proactor模型

Proactor模型Reactor模型的設(shè)計思想類似，都是基于事件分發(fā)機制。其中Reactor模型需要自己檢測接收讀寫事件，一旦檢測到有可接收可讀可寫等事件就分發(fā)到各類處理器上。而Proactor模型則是將分發(fā)器注冊到操作系統(tǒng)內(nèi)核中，內(nèi)核一旦完成了某些事件后就會通知分發(fā)器，然后分發(fā)器再分發(fā)到各類Handler（處理器）上。兩者最大的不同是對IO的操作方式，Reactor是基于應(yīng)用層發(fā)起的同步IO操作，而Proactor則是基于內(nèi)核的異步IO操作，應(yīng)用層先注冊到內(nèi)核并由內(nèi)核負責事件通知。

根據(jù)下圖看看Proactor的工作原理。首先應(yīng)用層創(chuàng)建分發(fā)器Dispatcher并注冊到內(nèi)核異步IO處理器中，它能夠感知已完成接收操作、已完成讀操作、已完成寫操作等事件。然后當有相應(yīng)事件發(fā)生時內(nèi)核會通知分發(fā)器，進而調(diào)用對應(yīng)的處理器Handler進行處理。最后如果Handler需要讀寫則可以直接對內(nèi)核緩沖區(qū)進行操作，此時數(shù)據(jù)肯定是已經(jīng)準備好了的。

Actor模型

Actor模型由Carl Hewitt在1973年發(fā)明，該模型實際上提供了一種更高層次的并發(fā)語義，通過該模型我們能夠通過Actor實體概念來進行并發(fā)編程，這些Actor之間通過郵箱來傳遞消息。簡單地來說就是，每個Actor里面都有自己的狀態(tài)、行為和郵箱，接收到消息后會執(zhí)行相應(yīng)的行為進行邏輯處理。此外還有一個重要的點，Actor與Actor之間是不共享狀態(tài)的。

Actor模型出現(xiàn)后，我們再也不必接觸到多線程和線程池等之類的基礎(chǔ)概念了，我們只需將重心放在邏輯處理和消息傳遞上，這是一種簡化并發(fā)編程的方法。反過來看傳統(tǒng)的并發(fā)編程，數(shù)據(jù)都是共享的，多個線程會并發(fā)的訪問這些共享數(shù)據(jù)，這就導(dǎo)致我們必須要面對繁雜的鎖、同步等等并發(fā)問題。而Actor則通過不共享狀態(tài)和消息傳遞來屏蔽這些復(fù)雜的問題，當然實際上底層實現(xiàn)也仍然會遇到這些并發(fā)問題，但對于開發(fā)者層面卻不必面對這些問題。

下面看Actor模型的具體內(nèi)容，實際上任務(wù)物體和概念都可以抽象為Actor，也就是萬物皆Actor。每個Actor都包含自己的狀態(tài)、行為以及郵箱，由于Actor之間是完全獨立的且狀態(tài)不共享，所以必須通過郵箱來傳遞消息。每個Actor可以看成是一個輕量線程，所以每個Actor最多只能同時進行一個工作。最后需要注意的是，消息的傳遞是完全異步且消息是不可變的。

CSP模型

CSP模型即通信順序進程（Communicating Sequential Processes），由托尼霍爾在1978年發(fā)明的一種并發(fā)模型。它看起來跟Actor的思想有點像，也通過消息傳遞避免并發(fā)過程中鎖和同步等問題，從而簡化并發(fā)編程。CSP模型主要有Processor和Channel兩個概念，其中Processor表示執(zhí)行任務(wù)順序單元，而Channel則表示消息交互通道，可以傳遞數(shù)據(jù)消息。每個Processor之間都是相互獨立的，它們只能通過Channel來通信。Actor模型中每個Actor都包含一個郵箱，它們之間是強耦合的，但CSP模型中卻不是這樣，Processor不包含Channel，它們之間是相互解耦的。

總結(jié)

本文主要介紹了并發(fā)模型相關(guān)的知識，首先介紹了并行和并發(fā)以及并發(fā)模型，然后從進程線程角度講解了單進程-多線程、多進程-單線程以及多進程多線程三種映射模式，最后介紹了五種常見的并發(fā)模型設(shè)計：Fork/Join模型、Reactor模型、Proactor模型、Actor模型和CSP模型