任何過去做過多線程開發的開發人員都知道管理多線程應用有多麼困難，多麼痛苦。這兒說的是“管理”，因爲多線程開始開發還是蠻簡單，並且看到有性能提升時還是蠻有趣的一件事。但是當你沒有簡單方式能夠從子任務中的錯誤中恢復，或者你發現的殭屍Bug很難重現，或者分析工具顯示線程在寫共享狀態上阻塞太多時間還是很都疼的事。
我不想談論Java的併發API和集合框架如何讓這個過程更好更簡單，既然你在看這篇文章，你肯定想在子任務上有更強的控制，或者你不喜歡寫鎖和同步塊，更希望有一些更高層次的抽象。
什麼是ACTOR?
Akka的Actor符合Actor Model
把Actor當做是人，他們之間並不直接跟彼此交流，而是通過郵件進行，下面詳細說一下
1. 消息傳遞
這基本概括了Actor模型裏消息傳遞的基本邏輯
考慮一下兩個人，一個老師和一個學生。每天早晨學生都向老師發一封郵件，老師也向學生回覆一個封。
需要注意的是：
- 學生髮送郵件，一旦發送，郵件就不能再編輯了。這叫自然不變性
- 老師在想查看郵件時採取檢查信箱
- 老師會向學生回覆一封（也是不可變的）
- 學生也會在需要的時候去查看郵箱
- 學生不會一直等待老師的回信（非阻塞）
這基本概括了Actor模型裏消息傳遞的基本邏輯
模型裏消息傳遞的基本邏輯
2. 併發
現在，我們想象一下有三個老師，三個學生，每個學生都向三個老師發送郵件。會發生什麼呢？實際上什麼都沒變，每個人都有自己的郵箱。需要注意的是：默認情況下，信箱中的郵件都是按照收到的順序被讀取或處理的。其實，內部默認是 ConcurrentLinkedQueue.
由於沒人會等待郵件被處理，所以其實就是一個非阻塞消息（其實有很多內置的信箱，包括有邊界的以及基於優先級的。事實上，我們自己也是可以實現一個的）。
3. 容錯
想象一下這三個老師來自不同的部門：歷史，地理和哲學。
歷史老師回覆關於歷史的郵件，地理老師回覆關於地理的郵件等等。每個學生髮送給每個老師的消息都會得到回覆。學生不關心是哪個部門的老師回覆的消息。一旦有一天，一個老師生病了，在這個部門中至少應該有一個老師負責處理郵件。這種情況下，部門中的另一個老師進來，回復學生的郵件。
需要注意的點：
-
這裏邊可能有很多Actor，並且他們做的都是不同的事
-
Actor執行過程中可能引起異常，但是並不能自我恢復。這種情況下，新的Actor會被創建出來去替換掉老的Actor。另外，Actor還可以僅僅忽略一個特殊的消息，進而去處理剩下的消息，這叫做Directives，後邊會詳細討論。
4. 多任務
我們假設當學生向老師問考試得分時，這些老師也是可以通過這些郵件來給他們發送考試分數的。同樣Actor也可以方便的處理多種類型的消息。
5. 鏈接
如果學生只想獲取一個統一的消息而不是三個呢。
我們也是可以通過Actor來實現類似的需求。我們可以把老師鏈接起來形成層級結構。後邊我們談及Supervisor的時候回重新細談這部分內容。
Actor Model：
這裏學生和老師就是我們的Actor。收件箱裏的郵件就是Mailbox組件。請求和回覆都是不可修改的，他們都是immutable對象。最後，Actor中的MessageDispatcher組件來管理mailbox和路由消息到對應的mailbox。
好了，看些代碼吧