4

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

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

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

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

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

4

1 回答 1

7

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

这当然不是那个意思。短语“更不可预测的性能”只是在谈论性能——而不是违反线程安全或 Java 集合合同。

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

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

你们中的任何人在使用 LinkedBlockingQueue 时遇到过任何问题吗？

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

于 2012-08-30T23:08:10.987 回答