我在其中并发是通过把几个工作单元上，一个消息驱动bean（MDB）的多个实例收听到消息队列实现的数据处理应用程序。其他则以这种方式实现并发性，我们没有任何具体的理由来使用消息传递基础结构和MDB。消息（例如JMS）何时是多线程的替代品？
这使我想到，为什么同已经不能使用多线程来实现的。
所以我的问题是，在什么情况下可以使用异步消息传递（例如JMS）作为实现并发的手段来替代mutithreading？使用一种方法比另一种方法有什么优点/缺点。
它不能用作多线程的替代品，它是实现多线程的一种方式。这里有三种基本的解决方案：
接收数据是在这里踢球，因为真的没有这样做，如果没有某种形式的多线程/多的，否则你将只处理一次一个请求的方式。在没有多线程的情况下发送数据更加可行，但您只是将处理这些消息的责任推到了外部系统。所以它不是多线程的替代方案。
对于使用消息驱动Bean的情况，容器正在为您创建和管理线程，因此它不是多线程的替代方法，而只是使用其他人的实现。
性能方面的多线程应该比任何消息传递更快，因为你添加了一个额外的消息传递网络层。
应用明智的消息可以帮助您避免锁定和数据共享的问题，因为没有共同的目标。
从比例的角度消息是好了很多，你可以通过配置信息服务，而不是更改应用程序配置多个服务器上的只是更多的节点。
消息传递可以大大减少多线程应用程序中的错误数量，因为它可以降低数据竞争的风险。它还简化了添加新线程而无需更改应用程序的其余部分。
虽然我认为JMS略微这里滥用。 java.util.concurrent的线程安全队列和类库如jetlang可能会为您提供更好的性能。
实际上，在EJB容器中，没有其他选择，因为您不允许在EJB容器中创建自己的线程。 JMS正在为您完成所有这些工作，但需要通过队列处理器运行它。你也可以创建一个Java Connector，它与容器有更密切的关系（因此可以有线程），但是这需要更多的工作。
如果使用JMS队列的开销不会对性能产生影响，那么这是最简单的解决方案。
技术上你不应该在J2EE容器创建线程，但它是相当常见的人做这里面的Web容器。 J2EE规范应该被视为比规则更多的指导原则。毕竟它也不允许直接访问文件系统，但人们总是用配置文件等来完成这个任务。特别是使用Spring时。 – cletus 2009-10-20 06:56:16
还有两个额外的奖金，我不认为已经提到过：交易和耐用性。
虽然它不是必需的，往往不是默认配置，JMS提供者可以被配置为持续的信息，同时参加在很少或根本没有代码变化的XA事务。
没错，就是解耦系统/模块的一个非常好的方式。它使系统的系统对服务器崩溃等技术问题更具有弹性。 – 2009-10-20 09:27:19
在大多数情况下，异步消息*是*多线程 – skaffman 2009-10-20 08:58:33