[concurrency-interest] Any fix for bug 6460501: AbstractQueuedSynchronizer$Node memory leak in BlockingQueues
dl at cs.oswego.edu
Sun Dec 3 19:00:00 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.
This was, in retrospect, a design flaw in AQS: Originally,
internal nodes used in timeouts were only GCable when
a lock/condition/whatever was ever triggered. This turns out
not to be good enough when people continually time out on
events that never occur. So we've added mechanics to
clean out nodes even in these cases. Unfortunately, due
to missing freeze deadlines (months ago now), the full set
of them aren't even going to be in FCS of Java 6, but
will make some update release. (I did finally check the
last of these into our CVS though.) Sorry about that.
> Any suggestions for a fix or a work-around?
One workaround is to somehow occasionally trigger whatever
you are waiting for. Better though is to not continually use
short-time timeouts for things that never happen. Even
changing to use an exponential backoff would limit damage.
More information about the Concurrency-interest