有限容量BlockingQueue
也是有用的,如果你想限制某種請求。憑藉無限的隊列,生產者可以遠遠領先於消費者。這些任務最終會被執行(除非有太多它們會導致OutOfMemoryError
),但製片人可能早已放棄,所以這些努力被浪費了。
在這樣的情況下,最好向潛在生產者發出隊列已滿的信號,並迅速放棄故障。例如,生產者可能是一個Web請求,用戶不希望等待太久,即使它在等待期間不會消耗很多CPU週期,但它正在使用有限的資源,如套接字和一些內存。放棄將使已經排隊的任務已經有更好的機會及時完成。
關於修改後的問題,我正在解釋爲「什麼是在池中保存對象的好集合?」
無邊界LinkedBlockingQueue
是許多游泳池的不錯選擇。但是,根據您的池管理策略,ConcurrentLinkedQueue
也可能工作。
在一個池應用程序中,阻塞「put」是不合適的。控制隊列的最大大小是池管理器的作業,它決定何時創建或銷燬池的資源。游泳池的客戶借用游泳池並返回資源。添加一個新對象或將以前借用的對象返回到池中應該是快速的非阻塞操作。所以,一個有界的容量隊列並不是池的好選擇。
另一方面,從池中檢索對象時,大多數應用程序都希望等待資源可用。至少暫時阻止的「take」操作比「繁忙等待」重複輪詢直到資源可用爲止效率更高。在這種情況下,LinkedBlockingQueue
是一個不錯的選擇。借款人可以通過take
無限期阻止,或限制其願意阻止的時間爲poll
。
當一個客戶端根本不願意阻止,但有能力爲自己創建一個資源(如果該池爲空)的情況較少見。在這種情況下,ConcurrentLinkedQueue
是一個不錯的選擇。這是一個灰色地帶,它儘可能地共享資源(例如,內存)會很好,但速度更重要。在更糟糕的情況下,這退化爲每個線程都有自己的資源實例;那麼它會更有效率,而不會試圖在線程之間共享。
這兩個集合在併發應用程序中提供了良好的性能和易用性。對於非併發應用程序,ArrayList
很難被打敗。即使對於動態增長的集合,LinkedList
的每個元素開銷也允許帶有一些空插槽的ArrayList
保持競爭性的記憶方式。
感謝埃裏克森這樣一個很好的解釋。 它解決了我的問題。 – 2008-12-12 09:27:10