java - 当我们有 LinkedBlockingQueue 时，为什么要使用 ConcurrentLinkedQueue？

Question

我为什么要使用 ConcurrentLinkedQueue当我有 LinkedBlockingQueue ？我知道ConcurrentLinkedQueue是非阻塞的但是 LinkedBlockingQueue可以用作 ConcurrentLinkedQueue .我会用 put()/offer()插入方法和poll()去除方法。 poll()如果队列为空，方法不会等待。 LinkedBlockingQueue也是无界的。所以我可以使用它。

到目前为止我发现的差异是 ConcurrentLinkedQueue在 LinkedBlockingQueue 时使用带有比较和交换的硬件级同步机制正在使用 ReentrantLock .

Answer 1

主要区别在于 ConcurrentLinkedQueue 是无等待，而不仅仅是无锁 ( what's the difference? ) 而 LinkedBlockingQueue 本质上必须保持锁定。

您可以使用 LinkedBlockingQueue 和 poll 对 ConcurrentLinkedQueue 进行建模，但实现将保持锁定状态，从而减少您可以从系统。

这是一个公认的不精确的微基准测试，它检查在没有阻塞的情况下通过两个并发队列中的每一个传递 10,000 个对象的速度，并计算循环中对 poll() 的调用总数:

AtomicInteger total = new AtomicInteger();
ConcurrentLinkedQueue<Integer> q = new ConcurrentLinkedQueue<>();
Thread thread = new Thread(() -> {
    int remaining = 10000;
    while (remaining != 0) {
        total.incrementAndGet();
        if (q.poll() != null) {
            remaining--;
        }
    }
});
Integer[] first100 = new Integer[100];
for (int i = 0 ; i != 100 ; i++) {
    first100[i] = i;
}
long start = System.nanoTime();
thread.start();
for (int i = 0 ; i != 10000 ; i++) {
    q.add(first100[i%100]);
}
thread.join();
long runtime = System.nanoTime() - start;

这个想法是在没有其他处理的情况下测量队列的“吞吐量”。此任务在 11.23 毫秒内完成，在读取线程 (demo 1) 中使用 ConcurrentLinkedQueue 进行 60K 次迭代，使用 LinkedBlockingQueue (demo 2) 进行 23.46 毫秒/100K 次迭代.