線程的麻煩事兒，Actor能解決嗎？
馮諾伊曼體系中， CPU和內存居于核心的地位。
內存就像一個個的小格子，其中保存著程序要讀寫的值。
當只有一個線程來訪問內存的時候，事情非常簡單：
但是，當出現多線程的時候，就可能會出現互相覆蓋的危險：
在多線程并發執行的情況下，為了得到正確的結果，必須要加鎖。
看起來加鎖是一件輕松的事情， 但實際上并非如此， 讓我們看一個轉賬的例子：有兩個賬戶，賬戶A和賬戶B， 現在有一個線程1，要從賬戶A給賬戶B轉50元。
為了防止別的線程并發操作，相互覆蓋，它需要加鎖：
看起來沒有任何問題， 但是如果還有個線程，同時要從賬戶B 給賬戶A轉30元，它也采用了類似的加鎖辦法，就出問題了：
有個非常簡單的辦法來解決這個問題：對賬戶按次序加鎖 。例如所有線程都是先對賬戶A加鎖，然后對賬戶B加鎖，這樣死鎖消除了。
看到了吧，多線程并發編程一不留神就會出錯。
你以為多線程編程是這樣：
實際上寫出的程序是這樣：
而CPU利用率很可能是“一核有難，眾核圍觀”
鎖這么麻煩，能不能不用鎖?
換個思路，不把賬戶余額看成是簡單的值，而是一個黑盒子對象：
在這個黑盒子中，保存了賬戶的余額200。
你想存款了，就發一個存款的消息過來，想取款就發一個取款的消息過來，發完消息就可以撤離了(異步操作)。
不管是有一個消息，還是有100個消息，統統放到黑盒子的一個隊列中，然后讓Account這個黑盒子一個個順序處理， 對余額進行增加或減少。
外界無法看到余額，只能通過消息和這個黑盒子交互，黑盒子內部順序處理，自然不用加鎖。
這個黑盒子，就是Actor。
試一試用Actor方式來實現轉賬， 看看和之前有什么不同：
“轉賬 Actor” 收到轉賬50元的消息， 向賬戶A發送取出50元的消息， 向賬戶B發出存入50元的消息。
然后賬戶A 和 賬戶B 收到消息，進行處理。
非常清晰，根本不用鎖， 每個Actor都是獨立的個體，它們之間靠消息交互就行了。
可是，在轉賬過程中，如果有別的線程對賬戶A也做了操作，導致賬戶A余額不足，拋出了異常， 但是賬戶B繼續存入50元，那這個轉賬其實就出錯了!
這時候，我們想到了什么?對，就是事務的原子性：要么不做，要么全做。
所以需要讓這些Actor支持事務，這可真是有點麻煩，因為Actor之間是獨立的，消息的發送是異步的，現在轉賬卻要求存入和取出兩個操作需要同步進行，并且滿足原子性。
世界上果然沒有免費的午餐。
這里邊要解決兩個問題：
1. 賬戶A和賬戶B的Actor 需要互相等待，直到存入和取出的操作都完成，有任何一個沒完成(如拋出異常)，就要回滾。
2. 由于消息發送都是異步的，在執行一個事務的時候，可能有其他消息放入消息隊列，并且被處理，賬戶A和賬戶B的余額不斷地被改變，需要處理這種不斷變化的情況。
可以參考下大名鼎鼎的CAS的原理，每個事務開始的時候，記錄下原始的值，在提交的時候和當前值進行比較，如果相同，表示在這段時間內沒有修改，提交成功。否則，讀取當前的值，重做事務中的操作：
沒有加鎖，就是不斷地在嘗試，由于數據都是在內存中操作，頻繁地嘗試也不是什么大問題(在并發沖突不是很激烈的情況下)
用這種方式實現的事務， 做軟件事務內存(Software Transactional Memory)，簡稱STM。
總結一下，Actor看起來簡單，對于單個賬戶操作來說，是個很美妙的模型，因為賬戶之間是隔離的。 但是對于一致性要求比較高的場景，如轉賬，Actor模型就顯得有些笨拙了。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
