Phew. I can actually imagine ThreadLocals being a hassle in a multithreaded system regarding these leaks, as you can't really "check the value" of the "variable". Especially when the same thread type might behave differently at times.
Q On Mon, Sep 14, 2009 at 9:07 PM, Kevan Miller <kevan.mil...@gmail.com> wrote: > > On Sep 14, 2009, at 1:29 PM, Quintin Beukes wrote: > >> I assume that if you have a reference to one of these classes from >> outside the application then it can prevent some classes to be GC'ed, >> like a static reference you created in some global class? Is this >> mostly the case, or is it more specialized? > > That's pretty much it. All it takes is a strong reference to any application > object (object instance, class, etc). This reference will prevent the > ClassLoader from being GC'ed. And this in turn will prevent all of the > Classes loaded by the ClassLoader from being GC'ed. These strong references > can come from ThreadLocals, statics, non-static references, or even stack > references. > > Once you've generated a .hprof file, using post-mortem analysis, you can > identify the causes of the memory leaks... > > --kevan > > -- Quintin Beukes
