Actor模型不僅僅被認為是一種高效的解決方案 ，它已經在世界上一些要求最苛刻的應用中得到了驗證，為了突出Actor模型所解決的問題，本節首先討論傳統編程模型與現代多線程和多CPU的硬件架構之間的不匹配：

• 對面向對象中封裝(encapsulation)特性的挑戰
• 對共享內存在現代計算機架構上的誤解
• 對調用堆棧的誤解

[[278011]]

對封裝特性的挑戰

封裝(encapsulation)是面向對象編程(OOP)中的一大特性，封裝意味著對象內部的數據不能夠在對象外直接訪問，必須通過對象提供的一系列方法來間接進行訪問。對象負責公開對數據的安全操作的方法，以保護其封裝的數據的不變性。

在多線程下，多個線程同時調用同一個對象的方法來修改其內部封裝的數據時候，就會存在線程安全問題，這是因為封裝本身不確保對象內部數據的一致性，在不對對象的方法在修改數據施加一定同步措施時，對象內的數據就會在多線程訪問下變得不確定了。

一個解決該問題的方式就是，多線程訪問對象方法內數據時候施加一定同步措施，比如加鎖，加鎖可以保證同時只有一個線程可以訪問對象內的數據，但是加鎖會帶來昂貴的代價：

• 使用鎖會嚴重影響并發度，使用鎖在現在CPU架構中是一個比較昂貴的操作，因為當線程獲取鎖失敗后會把線程從用戶態切換到內核態把線程掛起，稍后喚醒后又需要從內核態切換到用戶態進行運行。
• 獲取鎖失敗的調用線程會被阻塞掛起，因此它不能做任何有意義的事情。即使在桌面應用程序中這也是不可取的，我們想要的是即使后臺有一個運行比較耗時的工作在運行，也要保證系統對用戶的一部分請求有響應。在后端應用中，阻塞是完全浪費資源的。另外可能有人認為雖然當前線程阻塞了，但是我們可以通過啟動新線程來彌補這一點，但是需要注意一點，線程也是一種昂貴的資源，操作系統對線程個數是有限制的。
• 另外鎖的存在，帶來了新的威脅，即死鎖問題的存在。

由于以上問題的存在，導致我們進退兩難：

• 如果不使用足夠的鎖，則不能保證多線程下對象中數據不受到破壞。
• 如果在對象中每個數據訪問是都加了鎖，則會導致系統性能下降，并且很容易導致死鎖的發生。

另外，鎖只能在單JVM內(本地鎖)很好的工作。當涉及到跨多臺機協調時，只能使用分布式鎖。但是分布式鎖的效率比本地鎖低幾個數量級，這是因為分布式鎖協議需要跨多臺機在網絡上進行多次往返通信，所以其造成較大的影響就是延遲。

小結：

• 對象只能在單線程情況下保證封裝的安全性，也就是保證對象封裝的數據的線程安全性。多線程下修改對象內的數據大多情況下會導致數據被污染，造成臟數據產生。在同一代碼段中有兩個競爭線程會導致違反每個不變式。
• 雖然鎖看起來是保證多線程下封特性比較直接的方式，但實際上使用鎖的效率低下，并且在任何實際規模的應用中都容易導致死鎖的產生。
• 本地鎖是我們經常使用的，但是如果嘗試將其擴展為分布式鎖，則是有代價的，并且其橫向擴展的潛力有限。

對共享內存在現代計算機架構上的誤解

在80-90年代的編程模型概念化地表示，寫入變量時候是直接把其值寫入主內存里面(這有點混淆了局部變量可能只存在于cpu寄存器中的事實)。在現在計算機硬件架構中，計算機系統中為了解決主內存與CPU運行速度的差距，在CPU與主內存之間添加了一級或者多級高速緩沖存儲器(Cache)，每個cache有好多cache行組成，這些Cache一般是集成到CPU內部的，所以也叫 CPU Cache。所以當我們寫入變量的時候實際是寫入到了當前cpu的Cache中，而不是直接寫入到主內存中，并且當前cpu核對自己cache寫入的變量對其他cpu核是不可見的，這即是Java內存模型中共享變量的內存不可見問題。

在JVM中我們可以把變量使用volatile關鍵字修飾或者使用JUC包中的原子性變量比如AtomicLong對普通變量進行包裝來保證多線程下共享變量的內存可見性，當然使用加鎖的方式也可以保證內存可見性，但是其開銷更大。既然使用volatile關鍵字可以解決共享變量內存可見性問題，那么為何不把所有變量都使用volatile修飾那?這是因為使用volatile修飾變量，寫入該變量的時候會把cache直接刷新會內存，讀取時候會把cache內緩存失效，然后從主內存加載數據，這就破壞了cache的命中率，對性能是有損的。

所以我們需要細心的分析哪些變量需要使用volatile修飾，但是即使開發人員意識到volatile可以解決內存不可見問題，但是從系統中找出哪些變量需要使用volatile或者原子性結構進行修飾也是一個困難的事情，這使得我們在非業務邏輯處理上需要耗掉一部分精力。

小結：

• 在現在多核CPU的硬件架構中，多線程之間不再有真正的共享內存，cpu核心之間顯示傳遞數據塊(cache 行)將和網絡中不同計算機之間傳遞數據一樣。 CPU核心之間通信和網絡通信的共同點比許多人意識到的要多。現在跨CPU或聯網計算機傳遞消息已成為一種規范。
• 除了通過使用volatile修飾共享的變量或使用原子數據結構保證共享變量內存可見性之外，一個更嚴格和原則上的方法是將狀態保持在并發實體本地，并通過消息顯式在并發實體之間傳播數據或事件。

對調用堆棧的誤解

提起調用堆棧( Call stacks)大家都耳熟能詳，但是其被發明是在并發編程不是那么重要時候，那時候多核cpu系統還不常見，所以調用堆棧不會跨線程，因此不會為異步調用鏈提供調用堆棧能力。

在多線程下，當主線程(調用線程)開啟一個異步線程運行異步任務時候，問題就出現了。這時候主線程會將共享對象放到異步線程可以訪問到的共享內存里面，然后開啟異步線程后主線程繼續做自己的事情，而異步線程則會從共享內存中訪問到主線程創建的共享對象，然后進行異步處理。

進行異步處理時候遇到的第一個問題是當異步線程執行完畢任務后，如何通知主線程?另外當異步任務執行出現異常時候該怎么做?這個異常將會被異步線程捕獲，并且不會傳遞給主調用線程。

理論上主調用線程需要在異步任務執行完畢或者出異常時候被通知，但是沒有調用堆棧可以傳遞異常。異步任務執行失敗的的通知只能通過輔助方式完成，比如Future方式，將錯誤碼寫到主調用線程所在的地方，否則一旦準備好就希望得到結果。如果沒有此通知，則主調用線程將永遠不會收到失敗通知，并且任務將丟失!這類似于網絡系統的工作方式，其中消息/請求可能會丟失/失敗而不會發出任何通知。

當真的發生錯誤時，這種情況會變得更糟，當異步工作線程遇到錯誤時候會導致最終陷入無法恢復的境地。例如由錯誤引起的內部異常會冒泡到線程的根，并使線程關閉。這立即引發了一個問題，誰應該重新啟動該異步線程執行的任務，以及如何將其還原到已知狀態?乍一看，這似乎是可以管理的，但我們突然遇到了一個新的現象：異步線程當前正在執行的實際任務我們并沒有存放起來。實際上，由于到達頂部的異常使所有調用棧退出，任務狀態已經完全丟失了!即使這是本地通信，也沒有網絡連接，但是我們還是丟失了一條消息(可能會丟失消息)。

小結：

為了在當前系統上實現任何有意義的并發性和提高性能，線程必須以高效的方式在彼此之間委派任務，而不會阻塞。使用這種類型的任務委派并發(甚至在網絡/分布式計算中更是如此)，基于調用堆棧的錯誤處理會導致崩潰。因此需要引入新的顯式錯誤信令機制，讓失敗成為域模型的一部分。

具有工作委派的并發系統需要處理服務故障，并需要具有從故障中恢復的原則方法。此類服務的客戶端需要注意，任務/消息可能會在重新啟動期間丟失。即使沒有發生損失，由于先前排隊的任務(較長的隊列)或者垃圾回收導致的延遲等，將會導致響應可能會被任意延遲。面對這些情況，并發系統應以超時的形式處理響應截止日期。