ConcurrentLinkedDeque对LinkedBlockingDeque

Question

我需要一个线程安全的LIFO结构，并发现我可以为此使用Deque的线程安全实现。Java7引入了ConcurrentLinkedDeque，Java6引入了LinkedBlockingDeque。

如果我只使用LinkedBlockingDeque中的非阻塞方法(如addFirst()和removeFirst() )，那么它与ConcurrentLinkedDeque有什么区别吗？

也就是说，如果您忽略阻塞方面，ConcurrentLinkedDeque和LinkedBlockingDeque除了LinkedBlockingDeque是有界的之外，还有其他的区别吗？

Answer 1

有两件事：

1:如果我只使用LinkedBlockingDeque中的非阻塞方法(如addFirst()和removeFirst() )，它与ConcurrentLinkedDeque有什么区别吗？

在LinkedBlockingDeque中，这些方法在并发锁定行为方面确实存在差异。

public E removeFirst() {
        E x = pollFirst();
        ..
    }
 public E pollFirst() {
        lock.lock(); //Common lock for while list
        try {
            return unlinkFirst();
        } finally {
            lock.unlock();
        }
    }

类似于addFirst方法。在ConcurrentLinkedDeque中，这两个方法的这种锁定行为是不同的，而且效率更高，因为它不锁定整个列表，而是锁定其中的一个子集，检查ConcurrentLinkedDeque的源代码将为您提供更多的清晰信息。

2:来自ConcurrentLinkedDeque的javadoc的

注意，与大多数集合不同，size方法不是一个固定时间的操作。 。。 此外，批量操作( addAll、removeAll、retainAll、containsAll、equals和toArray )不能保证以原子方式执行。

以上不适用于LinkedBlockingDeque

Answer 2

引用伟大的道格·利亚 (我的重点)

LinkedBlockingDeque对ConcurrentLinkedDeque -- LinkedBlockingDeque类旨在成为“标准”阻塞deque类。当前的实现具有相对较低的开销，但可伸缩性相对较差的。..。 . ConcurrentLinkedDeque具有与LinkedBlockingDeque几乎相反的性能配置文件：相对较高的开销，但非常好的可伸缩性。..。在并发应用程序中，需要线程安全但不支持阻塞的Deque并不是很常见。而大多数这样做的人可能更适合用特殊情况的解决方案。

他似乎在建议您应该使用LinkedBlockingDeque，除非您特别需要ConcurrentLinkedDeque的特性。

Answer 3

ConcurentLinkedDequeue是无锁的(请参阅源代码中的注释)，而LinkedBlockingQueue使用锁定。也就是说前者应该更有效率。