我在其中併發是通過把幾個工作單元上，一個消息驅動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