对于我正在处理的日志记录功能，我需要有一个处理线程，它将等待作业并在计数达到或超过一定数量时分批执行它们。由于这是生产者消费者问题的标准案例，我打算使用 BlockingQueues .我有许多生产者使用 add() 方法向队列添加条目，而只有一个消费者线程使用 take() 在队列中等待。
LinkedBlockingQueue似乎是一个不错的选择，因为它没有任何大小限制，但是我很困惑从文档中阅读它。
Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications.
他们没有清楚地解释这个声明的含义。有人可以解释一下吗？这是否意味着 LinkedBlockingQueue 不是线程安全的？你们中有人在使用 LinkedBlockingQueue 时遇到过任何问题吗？
由于生产者的数量更多，我总是会遇到这样一种情况，即队列因要添加的大量条目而不堪重负。如果我使用 ArrayBlockingQueue相反，它将队列的大小作为构造函数中的参数，我总是会遇到容量已满相关的异常。为了避免这种情况，我不确定如何确定我应该用什么大小来实例化我的 ArrayBlockingQueue。您是否必须使用 ArrayBlockingQueue 解决类似的问题？
最佳答案
Does it mean LinkedBlockingQueue is not thread safe?
当然不是那个意思。 “不可预测的性能”这个短语所指的只是 - 性能 - 不是对线程安全或 Java 集合契约的一些违反。
我怀疑这更多是因为它是一个链表，因此迭代和集合上的其他操作会变慢，因此该类将持有锁的时间更长。它还必须处理更多的内存结构，因为每个元素都有一个链表节点，而不仅仅是数组中的一个条目。这意味着它必须在同步时刷新处理器之间更多的脏内存页。同样，这会影响性能。
他们想说的是，如果您可以，您应该使用ArrayBlockingQueue，否则我不会担心。
Did any of you encounter any issues using LinkedBlockingQueue.
我已经使用了很多，没有发现任何问题。它也在随处使用的 ExecutorService 类中大量使用。
关于java - "less predictable performance of LinkedBlockingQueue in concurrent applications"是什么意思？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12206840/