Backport: ConcurrentLinkedQueue/BlockingLinkedQueue Memory Leak?
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
More information about the Concurrency-interest