[concurrency-interest] Backport: ConcurrentLinkedQueue/BlockingLinkedQueue Memory Leak?

Brian O'Connell broconne at vt.edu
Sun Mar 26 17:00:11 EST 2006

   I am seeing some odd behavior in a project I am working on.  I have a 
system that contains 5 work queues all of which have objects put on the 
queue with add() and removed with a poll() until null loop.
I found that after sometime, perhaps in the area of 10 minutes I run out 
of memory.  I had this occur with both the ConcurrentLinkedQueue and the 
BlockingLinkedQueue implementations.  If I change to an
ArrayBlockingQueue I never see this behavior (and I also never throw an 
IllegalStateException so I am not putting too many objects on the queue).
   In debugging this I had a thread print out the return from size() on 
all 5 queues every second.  None of them ever grew larger than 9000 
(another thread was inserting 9000 entries per second on one of the 
queues.)  However, when I ran out of memory I analyzed the heapdump and 
had over 2 million ConcurrentLinkedQueue$Node or 
BlockingLinkedQueue$Node objects in memory.
   I am using version 2.0 from August.  I was wondering if this is a 
reported bug?  I imagine if not, then there must be a bug somewhere else 
in my program but I have yet to locate it.  I found this entry by Doug 
describing some leak condition, but I can't tell if it is the same 
because I never poll() with a timeout. 
   I see version 2.1 is available but in the release history I saw no 
mention of the issue I am seeing so I am leery of blindly upgrading and 
possibly masking this issue until it occurs at a much worse time than 
stress testing.


More information about the Concurrency-interest mailing list