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