英文原文連結，譯文連結，原文作者：Arun Manivannan ，譯者：有孚

寫過多執行緒的人都不會否認，多執行緒應用的維護是件多麼困難和痛苦的事。我說的是維護，這是因為開始的時候還很簡單，一旦你看到效能得到提升就會歡呼雀躍。然而，當你發現很難從子任務的錯誤中恢復或者有些殭屍BUG很難復現再或者你的分析器顯示你的執行緒在寫入一個共享狀態前大部分時間都浪費在阻塞上面的時候，痛苦降臨了。

我刻意沒提Java的併發API，以及它裡面的集合類使得多執行緒程式設計變得多麼輕鬆簡單，因為我相信既然你們點進了這篇文章，那就說明你希望能更好地控制你的子任務，或者你就是不喜歡使用鎖以及同步塊，希望能有一種更高層次的抽象。

在本系列的Akka筆記中，我們將通過一些簡單的Akka例子來體驗下它的諸多特性。

什麼是Actor?

Akka中的Actor遵循Actor模型。

你可以把Actor當作是人。這些人不會親自去和別人交談。他們只通過郵件來交流。

我們來稍微解釋下這點。

1. 訊息傳遞

假設有兩個人——一個聰明的老師和一個學生。學生每天早上都會發一封郵件給老師，而老師則會回覆一句名言。

需要注意的地方：

1. 學生髮送郵件。一旦傳送成功，郵件不能再修改。這天然就具備了不可變性。
2. 老師會自己決定何時檢查郵箱。
3. 老師還會回覆一封郵件。
4. 學生會自己決定何時檢查郵箱。
5. 學生不會一直等待回信（非阻塞的）。

這就可以總結出Actor模型的一個基本特徵——訊息傳遞。

2. 併發

現在，想像一下3個聰明的老師和3個學生——每個學生都會向所有老師分別傳送筆記。這會發生什麼？事實上沒有任何改變。每個人都有自己的郵箱。這裡有一點值得強調一下：

預設情況下，郵箱中的郵件是按它們到達的順序進行處理的。

3. 失敗處理

想像下這三個老師是不同系的——歷史，地理以及哲學。

歷史老師對過去的某個事件進行了評論，地理老師則傳送了一個很有意思的地方，而哲學老師回覆了一句名言。每個學生都分別給各個老師傳送郵件並收到回信。學生並不關心郵件到底是系裡的哪個老師回覆的。如果有一天有個老師生病了呢？系裡至少得有一個老師在處理郵件才行。這樣的話，系裡的另一位老師就會頂上這項工作。

需要注意的地方：

1. 會有一個Actor的池，每個Actor會處理不同的事件。
2. Actor做的事情可能會丟擲異常。它自己無法從中恢復。這種情況下，需要再生成一個新的Actor來頂替它。換句話說，這個新的Actor會忽略剛才那條訊息，繼續處理剩餘的訊息。這些也被稱為指令（Directive），後面我們會再講到它們。

4. 多工

我們假設下每個老師都會通過郵件來發送考試成績，如果學生這麼要求的話。類似的，Actor也可能會處理多種型別的訊息。

5. 訊息鏈

那如果學生不想收到多封郵件，而是一封該怎麼辦呢？

Actor同樣可以完成這個。我們可以將老師進行分層。後面我們講到Supervisor和Future的時候會再回來講下這點。

應Mohan的要求，我們把類比的實體和Actor模型中的元件做一下對映。

學生和老師都是我們的Actor。收件箱就是Mailbox元件。請求和響應是不可修改的。它們都是不可變物件。最後，Actor中的MessageDispatcher元件會管理郵箱並將訊息路由到對應的Mailbox中。

說得夠多的了，我們來寫下程式碼吧…

未完待續…

本文最早釋出於我的個人部落格: Java譯站