為什麼我覺得 Actor 很難用？

1樓：

是可以完全不用鎖的，至少在使用者態。綁核全走非同步就行了，比如 seastar.io

非要說硬體鎖也是鎖。。。那就是鑽牛角尖了

2樓：Vincent Zhang

題主你說得對，Actor確實就是通過區域性序列解決併發的。併發是Actor必須要解決的問題，而Actor的存在並不僅是為了解決併發。。。

而你說的FP，immutable，只是Actor採用的方法，而不是Actor的目的。

Actor的主要目的是：1. 減少阻塞 2.高可用 3.伸縮性

這三個問題，看起來感覺有點眼熟啊。。。

乙個萬惡的資本家要運營乙個公司，他希望達到： 1.員工最好別閒著 2.某些員工跳槽了公司也能繼續下去 3.活多幹不過來就多招人，活少有人閒著就裁員。

看看自己每天收郵件接需求，寫郵件交任務，活多了讓老闆排一下優先順序，某個任務被block住，也不會幹等著，而是報告老闆後立即開始做下乙個任務。自己不就是乙個勤勞的Actor麼。。。

這裡Actor與其說是演員，不如說是「採取行動的人」或者「執行者」。。。

乙個可以用Actor完成系統架構的工程師去當老闆，可能比那些讀完EMBA老闆還要有效率得多（逃

3樓：cloudfreexiao

actor 是幾種併發模型之一，actor csp 都是讓比傳統的執行緒鎖更可控當然都有各自的問題

scala erlang 都只是用其思想實現還是個不相同的另外 actor 才是真正的oop 好不好用需要看場景ps 我喜歡actor 函式式風格

4樓：宸風

上面答案說了很多了。

actor是一種思想，akka或erlang process只是對應的實現方式。

當你的非同步事件足夠多的時候，你便會發現這種模式是個解決這類問題的非常好的辦法之一。同時一般你還要考慮容錯，分布式通訊等問題，像akka這種框架提供了比較完整的解決方案。你如果非要把整個本來就同步的系統變成actor方式，自然會覺得彆扭。

不好用只能說可能你還沒遇到適合的場景，以及你還不夠上手。

5樓：小寺川

出現資源競爭的情況就是出現了多執行緒執行actor，這違背actor編碼原則，需要fork children actor。merge的時候由於還是單執行緒所以不會出現RC

6樓：Frank 李先生

看了所有答案，沒人提到不可變資料嗎？

就算使用了actor（假設使用執行緒來模擬actor），如何保證每個actor訪問訊息的時候是獨佔的，不會在讀的同時有其他actor去改變這個訊息？為什麼這個概念是函式式程式設計先提出來的？

使用actor或者多執行緒其實並不能保證解決併發複雜的問題，問題的根源其實是共享狀態的訪問控制。所以如果保證每個訊息傳遞的是資料的複製，而不是同一塊記憶體的引用，即可最大程度減少鎖的使用，減少共享狀態。

當然非函式式語言也可以用這種思想，用多執行緒模擬actor，然後保證所有執行緒使用的資料immutable就可以了。

7樓：

就是不想要你，隨便找個藉口而已，還當真了。原因可能是各種各樣的，比如這個職位剛好已經招到人了，但是之前已經通知了你來面試。或者就是顏值不高啦……

8樓：「已登出」

看到乙個個技術分析的答案我也是醉了。這事明顯是面試官聽到題主說【唯一手段】後，覺得題主天真，不想收留題主，而故意隨便找個藉口比如Actor來攆走題主而已，還都當真了......

9樓：李李

看了半天，好像就是用訊息佇列將併發操作變成單執行緒操作。理論上每個執行緒占用的資源不衝突的話當然可以不用鎖，只要保證訊息佇列讀寫不出錯就行

10樓：jamesr

請問有哪些同步和鎖的使用場景是Actor無法實現的？

按知乎流行語：先問是不是…

比如競爭資源問題：資源由Actor管理，其他的Actor競爭使用，則管理的Actor有仲裁權。