使用Scala Actors而不是JMS有什么区别？
例如，从性能和可伸缩性的角度来看，与JMS相比，Scala Actor模型添加了什么？在哪些情况下使用Actors而不是JMS更有意义，即Actors解决了JMS无法解决的问题？
答案 0 :(得分：112)
JMS和Scala演员具有理论上的相似性，但并不认为它们必然在架构上解决相同的问题。 Actors意味着是共享内存并发的轻量级替代方法，其中种族和死锁通常更难以意外创建。 JMS是一个复杂的API，旨在跨越直接消息传递，发布/订阅，事务，EJB集成等。
与actor相当的最接近的JMS是消息驱动的bean，由非持久的非事务性非pub / sub队列支持。我称之为“简单的JMS bean”。
现在，问题。
性能是一件很难讨论的事情，因为JMS是一个规范而不是一个实现。在使用简单的JMS bean时，我希望性能大致相似，并且可能在时间和内存方面对演员有一点优势。当您向JMS添加功能（例如pub / sub，事务等）时，性能自然会进一步下降，但之后您会尝试将苹果与橙子进行比较。
至于可伸缩性，简单的JMS bean应该与actor完全一样地扩展。将事务添加到JMS组合中会自然地损害可扩展性，具体取决于事务的范围。
更广泛的问题是演员做了什么JMS不能。好吧，没有内置的pub子或事务，似乎演员从JMS中减去 - 而且广义上说这是真的。但事情就是这样：演员需要这么少的代码，我可以愉快地使用它们来实现非常精细的并发性。在普通的Java代码中，我可能会说“我不想搞砸JMS及其依赖项或它需要的代码等等，所以我只会生成一个线程，使用一个锁，并共享一个数据结构。”对于Scala演员，我更有可能说“我只是掀起演员并继续前进。”
在设计上也存在哲学上的差异。演员有一个简单的，内置的管理层次结构概念。演员通常用于“让它崩溃”设计。如果一个演员因某种原因而去世，那么另一个演员负责决定该怎么做，比如重新启动那个演员，杀死一堆演员并重新启动所有演员，或杀死一堆演员本身以便其他一些演员可以处理问题。这种事情可以附加到JMS上，但它不是API的核心，必须以某种方式在外部进行管理。
顺便说一句，对于一个Scala actor库，它更多地移动到JMS涵盖的领域，请参阅Akka。 Akka还为许多常见的行为者层次结构策略带来了一种声明式方法。