vk2*_*239 4 java concurrency producer-consumer blockingqueue
对于我正在处理的日志记录功能,我需要有一个处理线程,当计数达到或超过一定数量时,它将等待作业并批量执行.由于这是生产者消费者问题的标准情况,我打算使用BlockingQueues.我有许多生产者使用add()方法向队列添加条目,而只有一个使用take()在队列中等待的消费者线程.
LinkedBlockingQueue似乎是一个不错的选择,因为它没有任何大小限制,但是我很困惑从文档中读取这个.
链接队列通常具有比基于阵列的队列更高的吞吐量,但在大多数并发应用程序中具有较低的可预测性能.
没有清楚地解释这个陈述的含义.有人可以点亮吗？这是否意味着LinkedBlockingQueue不是线程安全的？你们有没有遇到任何使用LinkedBlockingQueue的问题.
由于生产者的数量要多得多,因此总会有一种情况我可以遇到队列被大量条目淹没的情况.如果我改为使用ArrayBlockingQueue,它将队列的大小作为构造函数中的参数,我总是会遇到容量完全相关的异常.为了避免这种情况,我不知道如何确定我应该用实例化ArrayBlockingQueue的大小.您是否必须使用ArrayBlockingQueue解决类似的问题？
这是否意味着LinkedBlockingQueue不是线程安全的？
它的确不是那个意思.短语"不太可预测的性能"只是谈论 - 性能 - 而不是违反线程安全或Java收集合同.
我怀疑这更多的是它是一个链接列表,所以迭代和集合上的其他操作将更慢,所以类将持有更长的锁.它还必须处理更多的内存结构,因为每个元素都有一个链表节点而不是数组中的一个条目.这意味着在同步时必须在处理器之间刷新更多脏内存页.同样,这会影响性能.
他们想说的是,如果可以的话,你应该使用它ArrayBlockingQueue,否则我不会担心它.
你们有没有遇到任何使用LinkedBlockingQueue的问题.
我经常使用它,没有看到任何问题.它在各个ExecutorService地方使用的类中也被大量使用.