在爲金融服務行業構建大型多線程應用程序時，我在任何地方都可以使用不可變類和Actor模型進行工作流。我對結果非常滿意。它使用相當數量的堆空間（它在Java btw中），但JVM的GC與短暫的不可變類完美配合。使用Immutability + Actor模型進行併發編程的缺點是什麼？
我只是想知道是否有任何缺點使用這種模式向前？在調試團隊配對代碼時，我經常發現自己以這種或那種方式推薦這種模式。我想一旦有人拿着錘子，一切都看起來像釘子。所以問題是：這種設計模式（範式？）什麼時候會效果不佳？
我的預感是，當內存使用是一個很大的問題，或者當項目限制要求沿着低級別的C線的東西，等
許多科學的模擬代碼是真的佔用大量內存。例如，對於元胞自動機模型，快速存儲器訪問比CPU功率更重要。在這種情況下，訪問和修改可變數組總是更快（至少在我所有的試驗中）。
全部取決於您的項目設計。
如果你有一些資源和很多演員使用它，那麼常見的模式是設計訪問者角色。然後，當其他演員需要詢問某些資源時，他會詢問其配音演員。然後通過消息通道複製答案。
現在想象一下 - 你的資源非常沉重（如map[String, BigObject]），而其他演員經常會問一些BigObject，那麼你就浪費了你的帶寬。
更好的主意是將資源分享給只讀模式的所有演員，並讓一個演員執行寫入。
其他示例將數據庫連接器連接到數據庫與很多blob數據。當數據庫連接器是線程安全的（通常情況下），最好將連接器對象引用分享給所有參與者，然後設計一些提供訪問權限的actor。
所有你需要記住演員之間的每一次通信都是通過複製消息來完成的。
Akka不復制任何消息，它只是內存讀取。除非您在分佈式設置中運行，否則需要編組消息。 –
絕對的，但美麗是你可以混合和匹配，所以你可以使用Actors的通信，並使用像並行收集等東西的原始計算能力。 –
是的。這正是我們所做的。我正在處理「不可變的」部分。 – paradigmatic