LinkedList与ConcurrentLinkedQueue [英] LinkedList Vs ConcurrentLinkedQueue

问题描述

目前在多线程环境中，我们使用LinkedList来保存数据。有时在日志中，我们在轮询链表时获得NoSuchElementException。如果我们从linkedlist转到ConcurrentLinkedQueue实现，请帮助理解性能影响。

Currently in a multithreaded environment, we are using a LinkedList to hold data. Sometimes in the logs we get NoSuchElementException while it is polling the linkedlist. Please help in understanding the performance impact if we move from the linkedlist to ConcurrentLinkedQueue implementation.

谢谢，
Sachin

Thanks, Sachin

推荐答案

当你得到 NoSuchElementException 时，这可能是因为没有正确同步。
例如：你正在检查 it.hasNext（）如果一个元素在列表中，然后尝试用获取它it.next（）。当元素在两者之间被删除时，这可能会失败，并且当您使用Collection API的同步版本时也会发生这种情况。

When you get a NoSuchElementException then this maybe because of not synchronizing properly. For example: You're checking with it.hasNext() if an element is in the list and afterwards trying to fetch it with it.next(). This may fail when the element has been removed in between and that can also happen when you use synchronized versions of Collection API.

所以转移到问题无法真正解决您的问题的ConcurrentLinkedQueue 。你可能没有得到例外，但你必须准备好，即使你在它之前检查它是非空的，也会返回 null 。 （这仍然是相同的错误，但实现方式不同。）只要您的代码中没有正确的同步，并且在SAME同步范围内检查空白和元素检索，就是这样。

So your problem cannot really be solved with moving to ConcurrentLinkedQueue. You may not getting an exception but you've to be prepared that null is returned even when you checked before that it is not empty. (This is still the same error but implementation differs.) This is true as long as there is no proper synchronization in YOUR code having checks for emptiness and element retrieving in the SAME synchronized scope.

很有可能交易 NoSuchElementException 以获得新的 NullPointerException 之后。

There is a good chance that you trade NoSuchElementException for having new NullPointerException afterwards.

这可能不是直接解决你的性能问题的答案，而是 NoSuchElementException 在LinkedList中作为移动到 ConcurrentLinkedQueue 的理由听起来有点奇怪。

This may not be an answer directly addressing your question about performance, but having NoSuchElementException in LinkedList as a reason to move to ConcurrentLinkedQueue sounds a bit strange.

编辑

一些破坏实施的伪代码：

Some pseudo-code for broken implementations:

//list is a LinkedList
if(!list.isEmpty()) {
    ... list.getFirst()
}

正确同步的一些伪代码：

Some pseudo-code for proper sync:

//list is a LinkedList
synchronized(list) {
    if(!list.isEmpty()) {
        ... list.getFirst()
    }
}

破坏同步的一些代码（不按预期工作）。
这可能是直接从LinkedList切换到CLQ的结果，希望能够自己摆脱同步。

Some code for "broken" sync (does not work as intended). This maybe the result of directly switching from LinkedList to CLQ in the hope of getting rid of synchronization on your own.

//queue is instance of CLQ
if(!queue.isEmpty()) { // Does not really make sense, because ...
    ... queue.poll() //May return null! Good chance for NPE here!
}

一些正确的代码：

//queue is instance of CLQ
element = queue.poll();

if(element != null) {
   ...
}

或

//queue is instance of CLQ
synchronized(queue) {
    if(!queue.isEmpty()) {
        ... queue.poll() //is not null
    }
}

这篇关于LinkedList与ConcurrentLinkedQueue的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！