“并发应用程序中 LinkedBlockingQueue 的不可预测性能”是什么意思？

Question

对于我正在开发的日志记录功能，我需要一个处理线程来等待作业，并在计数达到或超过一定数量时分批执行它们。由于这是生产者消费者问题的标准案例，我打算使用BlockingQueues。我有许多生产者使用 add() 方法将条目添加到队列中，而只有一个消费者线程使用 take() 来等待队列。

LinkedBlockingQueue 似乎是一个不错的选择，因为它没有任何大小限制，但是我很困惑从文档中阅读此内容。

链接队列通常比基于数组的队列具有更高的吞吐量，但在大多数并发应用程序中的性能难以预测。

并没有清楚地解释这句话的含义。有人可以照亮它吗？这是否意味着 LinkedBlockingQueue 不是线程安全的？你们有没有人在使用 LinkedBlockingQueue 时遇到过任何问题。

由于生产者的数量要多得多，我总是会遇到这样一种情况，即队列被大量要添加的条目压得喘不过气来。如果我改用ArrayBlockingQueue，它将队列的大小作为构造函数中的参数，我总是会遇到与容量满相关的异常。为了避免这种情况，我不确定如何确定我应该用什么大小来实例化我的 ArrayBlockingQueue。您是否必须使用 ArrayBlockingQueue 解决类似的问题？

Answer 1

这是否意味着 LinkedBlockingQueue 不是线程安全的？

确实不是的意思。短语“更不可预测的性能”只是在谈论 -- 性能 -- 并且不是违反线程安全或 Java 集合合同。

我怀疑这更多是因为它是一个链表，因此对集合的迭代和其他操作会更慢，因此类将持有更长时间的锁。它还必须处理更多的内存结构，因为每个元素都有一个链表节点，而不仅仅是数组中的一个条目。这意味着它必须在同步时在处理器之间刷新更多的脏内存页。同样，这会影响性能。

他们想说的是，如果你可以，你应该使用ArrayBlockingQueue，否则我不会担心。

你们中是否有人在使用 LinkedBlockingQueue 时遇到过任何问题。

我用过很多次，没有发现任何问题。它在无处不在的ExecutorService 类中也被大量使用。