我目前正在研究一系列警報，這些警告將檢查來自外部Web服務的響應的狀態，並根據響應對象的狀態發送警報（用於例如超時，無效數據等）。我希望主線程在評估響應併發送警報時繼續工作。使用後臺線程與使用消息隊列
我提供給我兩個直接的選擇：
這兩個對我來說都是很不錯的選擇，但我傾向於使用線索命令，因爲我不需要消息隊列的大部分功能。
問題：你將如何決定使用哪一個？爲什麼？
兩個字：
保證交付。
如果這對你很重要，那麼消息隊列就是你想要的。
我會根據你已經在想什麼來決定......一個完整的消息隊列雖然非常強大，卻比你需要的方式更大。更不用說它是另一個進程/服務器/等等。所以，我會爲第二個選項投票。 :-)
是的，我也這樣傾斜。我應該提到activemq已經在這個應用程序中做了一堆東西，並且正在使用webapp運行在jvm上。 – 2011-05-18 00:35:00
這聽起來像是你在一起處理應用程序中的事件。爲此，您在java.util.concurrent包中有很多選項。消息隊列有利於保證傳遞（可以提供持久性）並允許消息傳遞給多個服務器。
util.concurrent的ExecutorService允許您提交要在線程池上執行的任務。它返回的將來可以讓你繼續處理並在稍後檢查結果。
Future<?> submit(Runnable task)
如果這不完全符合您的要求，那麼java.util.concurrent中可能還有其他選項。
這是一個很好的觀點 - 如果在整個集羣中這是必要的，消息隊列可能更有意義，但在這種情況下，因爲每個服務器只處理命令可以在每個服務器上進行線程化的一部分響應。另一方面，持續隊列將提高可靠性... – 2011-05-18 00:47:17
@Dave正確，它會提高可靠性。這是一個要求嗎？請記住，如果你的應用程序崩潰，如果事件丟失了，它是否重要？這取決於應用程序的類型，如果重要的話。 – 2011-05-18 00:49:43
在這種情況下，100％的可靠性並不是必需條件，但它不會損害任何事情以期望可靠的警報，並且我還沒有開始編寫代碼......您是否從您的一次資源成本體驗中獲得了一般意義與其他？ – 2011-05-18 00:52:42
這是真的。我可以使用一個持續隊列來提高重啓和其他服務器事件的可靠性。 – 2011-05-18 00:36:40