[concurrency-interest] Any fix for bug 6460501: AbstractQueuedSynchronizer$Node memory leak in BlockingQueues

Dawid Kurzyniec dawidk at mathcs.emory.edu
Fri Dec 1 13:01:20 EST 2006

David Walend wrote:
> I need your help with a leak of  
> java.util.concurrent.locks.AbstractQueuedSynchronizer$Node s I'm  
> seeing in a big application using SomnifugiJMS. In a profiler run of  
> about two hours, it's leaking about 250,000 instances in an idle  
> system. (Netbeans profiler says that is about 8 MB. I'm pretty sure  
> it's a big contributor to why we're running out of memory in 4-day  
> runs, but haven't made a profile run that long.) The allocation stack  
> trace says these are getting allocated when I call  
> PriorityBlockingQueue's poll() method with a timeout of 100 ms. I  
> think it only leaks when the call times out, but don't have good  
> evidence for that.
> I found bug 6460501 ( http://bugs.sun.com/bugdatabase/view_bug.do? 
> bug_id=6460501 ) which seems to be a match.
> We're committed to using Java5.
> Any suggestions for a fix or a work-around? Is there one already in  
> the concurrency backport?

There is jsr166.jar, updated on September 5, in which there is some fix 
labeled "Avoid memory leak on timeouts". I don't know if it fully solves 
the problem, I guess this is a question to Doug Lea. If yes, then I 
believe that by putting this JAR on your bootclasspath, you can override 
the platform's java.util.concurrent.

I suppose you could try using the backport as well. But don't use the 
backport version for "5.0", since it is using the native AQS and will 
probably suffer from the same problem. You would have to use standard 
1.4 backport, which does not rely on AQS at all, but it may have a 
performance impact. (Depending on the application, it may be 
unnoticeable, but it may be substantial, too).

Also, I would consider looking at the application logic, to see if you 
can avoid short timeouts in the first place. Short timeouts indicate 
that you're waiting for something else while trying to enqueue. Maybe 
you can write a specialized queue, that wakes up your putter thread once 
that something else happens?...


More information about the Concurrency-interest mailing list