I've read the blog, but i'm not sure whether his conclusion is correct :
http://www.javacodegeeks.com/2010/09/java-best-practices-queue-battle-and.html#ixzz1seaiSLwp
He said : As you can see from the provided performance results LinkedBlockingQueue achieved the best combined (adding and removing elements) performance results and should be your number one candidate for implementing producer – consumer schenarios.
I wonder that, doen't it faster if i don't use lock in my code ?
So why the LinkedBlockingQueue is faster than the lock-free Queue(ConcurrentLinkedQueue) ?
Thanks !
ConcurrentLinkedQueue is not a blocking queue. It does not implement the BlockingQueue interface, and therefore does not provide the blocking methods put() and take(). These methods are necessary for a producer/consumer setup, because you need to arrange for the consumer to block while there is nothing to consume, and for the producer to block when the consumers don't consume quickly enough.
LinkedBlockingQueue is a Deque and ConcurrentBlockingQueue is not. Check Javadoc for more details
This benchmark is weird : using the concurrent queue as a blocking queue make no sense or am I missing something. This code is not going to save the planet I guess :
and is of course less efficient than :