一.Actor模型介紹

在單核 CPU 發(fā)展已經(jīng)達到一個瓶頸的今天，要增加硬件的速度更多的是增加 CPU 核的數(shù)目。而針對這種情況，要使我們的程序運行效率提高，那么也應該從并發(fā)方面入手。傳統(tǒng)的多線程方法又極其容易出現(xiàn) Bug 而難以維護，不過別擔心，今天將要介紹另一種并發(fā)的模式能一定程度解決這些問題，那就是 Actor 模型。

Actor 模型其實就是定義一組規(guī)則，這些規(guī)則規(guī)定了一組系統(tǒng)中各個模塊如何交互及回應。在一個 Actor 系統(tǒng)中，Actor 是最小的單元模塊，系統(tǒng)由多個 Actor 組成。每個 Actor 有兩個東西，一個是 mailbox，一個是自身狀態(tài)。同時 Actor 有接收和發(fā)送的功能。下面代碼給出一個大概的 Actor 樣例：

trait Actor { //持有一個表示自身狀態(tài)的私有變量 val state:Integer = 0; //持有一個mailbox 的隊列 val mailBox:mutable.Queue[Message] = scala.collection.mutable.Queue[Message]() def send(message : Message): Unit ={ ... } def recive(): Unit ={ ... }}

當一個 Actor 接收到消息后，它會執(zhí)行下面三種操作中的一種：

需要注意的是，盡管許多 Actor 同時運行，但是一個actor只能順序地處理消息。也就是說其它 Actor 發(fā)送了三條消息給一個 Actor ，這個 Actor 只能一次處理一條。所以如果你要并行處理3條消息，你需要把這條消息發(fā)給3個actors。

下面這張圖展示了一個簡單的 Actor 模型系統(tǒng)：

了解了 Actor 模型的大概規(guī)則后，我們用兩個具體的例子來看看 Actor 模型的妙處以及不足吧。

二. 兩個例子

2.1 素數(shù)計算

假設(shè)我們現(xiàn)在有一個任務，需要找出100000以內(nèi)素數(shù)個數(shù)，并且使用多線程的方式實現(xiàn)。

下圖展示了使用共享內(nèi)存的方式和以Actor模型的方式進行并發(fā)執(zhí)行。

這里展示了兩種處理并發(fā)的不同思路，傳統(tǒng)的方式是通過鎖/同步的方式來實現(xiàn)并發(fā)，每次同步獲取當前值，并讓一個線程去判斷值是否為素數(shù)，是的話再通過同步的方式對計數(shù)器加1（這里的說明只是作為提供思路用，這種方法自然有很大的優(yōu)化空間）。

而使用 Actor 模型則不一樣，它將這一過程拆分成幾個模塊，即拆分成幾個 Actor 。每個 Actor 負責不同的部分，通過消息傳遞的方式讓這幾個 Actor 協(xié)同工作，并且其中涉及到主要計算的 Actor 可以有多個，通過多個 Actor 協(xié)同工作實現(xiàn)并發(fā)。

2.2 銀行轉(zhuǎn)賬

銀行轉(zhuǎn)賬的任務描述很簡單，假設(shè)有兩個用戶，現(xiàn)在用戶A向用戶B轉(zhuǎn)賬100元，這個 Actor 模型該如何設(shè)計呢？

用戶 A 和 用戶 B 明顯是兩個 Actor ，但我們同時還需要一個可以控制用戶A Actor 和用戶B Actor 的 Actor ，我們稱之為 轉(zhuǎn)賬管家 Actor。那么流程圖如下。

可以看到，當一個轉(zhuǎn)賬需求過來的時候，Actor 管家會先向 用戶A Actor 發(fā)送扣款 100 元的信息，接受到扣款成功消息后再發(fā)送消息給用戶B Actor，發(fā)送讓其增加 100 元的消息。

一切看起來都很美好是吧，但這里面有一個問題，那就是在用戶A Actor 扣款期間，用戶B Actor 是不受限制的，此時對用戶B Actor 進行操作是合法的！針對這種情況單純的Actor模型就顯得比較乏力了，需要加入其他機制以保證一致性。

看到這你就明白了，Actor 模型并非萬能的，它有一定的缺點。那就是針對一致性要求比較強的場景比較乏力。

三. 為什么會出現(xiàn) Actor 模型

接下來我們來聊聊為什么會有 Actor 模型這種并發(fā)編程模型出現(xiàn)。

我們需要先說說并發(fā)性中的一致性和隔離性。

一致性即讓數(shù)據(jù)保持一致，比如銀行轉(zhuǎn)賬例子中，用戶A 轉(zhuǎn)給　用戶B 100塊錢，沒有其他干擾的情況下，轉(zhuǎn)賬完成時。用戶A 的賬戶必然減少 100 元，用戶B 的賬戶必然增加100 元，這就滿足了一致性。不能說用戶A 減少50 或用戶B 增加了 200。

隔離性可以理解為犧牲一部分的一致性需求，而獲得性能的提高。打個比方，在完全一致的情況下，任務都是串行的，這時候也就不存在隔離性了。

明白這些之后，你就直到為什么會有 Actor 模型了。

傳統(tǒng)并發(fā)模式，共享內(nèi)存是傾向于強一致性弱隔離性的。比如悲觀鎖/同步的方式，其實就是使用強一致性的方式控制并發(fā)。而 Actor 模型天然是強隔離性且弱一致性，所以 Actor 模型在并發(fā)中有良好的性能，且易于控制和管理。

這樣你就明白 Actor 模型適合于什么樣的并發(fā)場景了，當對一致性需求不是很高的情況下且對性能需求較高時，Actor 模型無疑是一個值得嘗試的方案。

以上就是淺談JAVA Actor模型的一致性與隔離性的詳細內(nèi)容，更多關(guān)于JAVA Actor模型的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！