使用Immutability + Actor模型进行并发编程有哪些缺点?

时间:2011-10-13 02:44:06

标签: scala immutability akka

在为金融服务行业构建大型多线程应用程序时,我尽可能地使用不可变类和工作流模型。我对结果非常满意。它使用了相当数量的堆空间(在Java btw中),但JVM的GC在短期不可变类中运行良好。

我只是想知道今后使用这种模式是否有任何缺点?在调试团队配对代码时,我经常发现自己以这种或那种方式推荐这种模式。我猜一旦有人拿锤子,一切看起来像钉子。所以问题是:这种设计模式(范式?)什么时候会运作不佳?

我的预感是当内存使用是一个大问题,或者当项目限制需要低级别C等等时。

2 个答案:

答案 0 :(得分:5)

许多科学模拟代码实际上是内存密集型的。例如,对于蜂窝自动机模型,快速存储器访问比CPU功率更重要。在这种情况下,访问和修改可变数组总是更快(至少在我的所有试验中)。

答案 1 :(得分:5)

全部取决于您的项目设计。

如果你有一些资源和许多演员使用它,那么常见的模式是设计访问者角色。然后,当其他一些演员需要询问一些资源时,他会询问它是访问者演员。然后通过消息通道复制答案。

现在想象一下 - 你有非常繁重的资源(例如map[String, BigObject]),其他演员经常询问一些BigObject然后你浪费你的带宽。
更好的想法是以 readonly 模式向所有参与者共享资源,并让一个actor执行写入

其他示例是数据库连接器,它使用大量 blob 数据连接到数据库。当数据库连接器是线程安全的(通常情况下)时,最好将连接器对象引用共享给所有actor,然后设计一些提供访问权限的actor。

所有你需要记住演员之间的所有沟通都是通过复制消息来完成的。