我正在製作/準備基於生產者/消費者模型的應用程序。在我的情況下，將會有一個生產者產生幾個萬（非平凡）任務，並且將會有可配置數量的消費者。Java溢出到磁盤的FIFO隊列
生產者和消費者之間的溝通基本上是基於隊列的。我擔心的是內存消耗：可以想象的是，任務數量將超過JVM的可用內存。所以我想有一個Queue實現，它只保留內存中的「top-X」數量的隊列項目，並將其餘部分存儲在磁盤上。這並不一定要有彈性，因爲它不需要重新啓動程序。
我周圍搜索，但無法找到似乎在廣泛使用的隊列實現（似乎有一些，我稱之爲概念驗證實現，但我很擔心關於未來的支持/這些實現的持續發展）。我也研究了外部消息隊列應用程序，但是（1）我不想運行第二個外部進程，並且（2）即使在相同的JVM進程中嵌入消息代理似乎對於此要求有點「頭重腳輕」 。
有沒有人知道任何支持未來的良好支持未來的庫，它提供了這種功能？
Rgds
那麼，JMS似乎是明顯的解決方案。因爲JMS解決了這個問題，所以我認爲你不會找到可靠的解決方案來解決這個問題，它是一個標準的解決方案。
但是請注意，Java也有BoundedQueues來解決這個問題：維護隊列以確保它在隊列滿時不會因OOME而失敗，並且在嘗試將消息放入完整有界隊列，直到其中一個消費者從隊列中刪除某個任務。
的確，我已經考慮使用BoundedQueue（並且還沒有排除）。聽起來是這樣，製作生產者區塊效率不高。 – 2012-01-01 12:20:56
順便說一句。我不同意這樣的假設，即JMS存在並解決了這個問題，即沒有其他解決方案/實現的空間。對於這樣的事情，JMS嚴重地過分。例如，這個「限制內存的隊列」可能是嵌入式系統中的一個需求，在這個嵌入式系統中，沒有用於JMS消息代理的空間/資源。 – 2012-01-01 12:23:21
如果生產者對消費者而言過於快速，那麼阻止生產者將允許消費者爲他們分配更多的CPU時間（或帶寬），因此生產和消費許多任務所花費的總時間可能與一個磁盤備份的隊列（或者更低，因爲你避免了讀/寫磁盤的需要） – 2012-01-01 12:24:17
當有足夠多的任務需要使用時，擁有生產者塊通常比讓隊列增長並消耗更多內存更高效。例如如果您的隊列適合隊列，它可能會比沒有隊列的隊列快幾倍。
您是否曾經爲您的問題找到可靠的解決方案？我期待解決相同的情況。謝謝！ – joe 2016-05-02 19:25:24