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