「併發應用程序中LinkedBlockingQueue的可預測性較差」是什麼意思？

對於我正在處理的日誌記錄功能，我需要有一個處理線程，它將等待作業，並在計數達到或超過特定數量時分批執行它們。由於這是一個生產者消費者問題的標準案例，我打算使用BlockingQueues。我有許多生產者使用add（）方法將條目添加到隊列中，而只有一個使用take（）的消費者線程在隊列中等待。「併發應用程序中LinkedBlockingQueue的可預測性較差」是什麼意思？

LinkedBlockingQueue似乎是一個不錯的選擇，因爲它沒有任何大小的限制，但我很困惑從文檔中讀這個。

鏈接隊列通常具有比基於陣列的隊列，但在大多數併發應用較少預測的性能更高的吞吐量。

沒有清楚地解釋它們的含義。有人可以點亮它嗎？這是否意味着LinkedBlockingQueue不是線程安全的？使用LinkedBlockingQueue是否遇到任何問題？

由於生產者的數量多得多，我總是會遇到一種情況，即隊列被大量的條目添加到不知所措的地方。如果我使用ArrayBlockingQueue來替代，它將構造函數中的隊列大小作爲參數，我總是可以運行到容量完全相關的異常。爲了避免這種情況，我不知道如何確定我應該實例化ArrayBlockingQueue的大小。你是否需要使用ArrayBlockingQueue來解決類似的問題？

來源

2012-08-30 vk239

這是否意味着LinkedBlockingQueue不是線程安全的？

當然確實不是的意思是。「不太可預測的性能」一語正在談論 - 性能 - 和而不是一些違反線程安全或Java收集合同。

我懷疑這是更多的事實，它是一個鏈表，所以迭代和集合上的其他操作會更慢，所以類將持有更長的鎖。它還必須處理更多的內存結構，因爲每個元素都有一個鏈接列表節點，而不僅僅是一個數組中的條目。這意味着它在同步時必須在處理器之間刷新更多髒頁面。再次，這會影響性能。

他們想說的是，如果你可以，你應該使用ArrayBlockingQueue但除此之外，我不會擔心它。

您是否使用LinkedBlockingQueue遇到任何問題。

我用了很多，沒有看到任何問題。它在各個地方使用的ExecutorService類中也有很多用處。

來源

2012-08-30 23:08:10 Gray

感謝格雷關於「不太可預測的性能」的含義的詳細答案。由於您提到它們在任何地方都可以使用，因此它使我有信心使用LinkedBlockingQueue。 – vk239

在研究同一個問題時，讓我回答了這個問題。感謝您的回答，但如果性能不太可預測，那麼這些隊列通常比基於陣列的隊列有更好的吞吐量？直觀地看來，否則。 – shrini1000

有趣的@shrini。你看到了什麼證據？ – Gray

「併發應用程序中LinkedBlockingQueue的可預測性較差」是什麼意思？

回答

相關問題