Hi.
I agree wholeheartedly that ThreadLocals are great stuff for many
scenarios. For me, they make lots of sense for carrying some context
forward through method calls whose signatures you cannot or will not
change. And they're fast. And bla bla..
Great..
> In all of these cases, thread locals are the right thing to use. Can
> you cause unintended object retention with thread locals? Sure you
> can. But you can do this with arrays too. That doesn't mean that
> thread locals (or arrays) are bad things. Merely that you have to use
> them with some care. The use of thread /pools/ demands extreme care.
> Sloppy use of thread pools in combination with sloppy use of thread
> locals can cause unintended object retention, as has been noted in many
> places.
Did you read the links in my post?
The point is so: Tomcat is a widely used Servlet Container. ThreadLocals
works perfect for lots of stuff, and everyone is happy.
However, when a "web application reload" happens, the CURRENT
implementation of ThreadLocal will, given merely one non-nulled
ThreadLocal, and given that Tomcat don't kill _all_ its "worker Threads"
(the ones that have done service calls into the web app) upon any webapp
reload, retain a strong chain to the ThreadLocal's values, hence to
those object's classloader (which is the "now ditched" old webapp
classloader), and hence all the loaded classes. (And I guess further:
hence all those classes' ThreadLocals, which will ensure even better
that their values aren't GCable, since the "cleaning efforts" of the
ThreadLocal implementation will be even more hampered).
One can argue that the application should never let a Thread get out of
the webapp scope with any webapp scoped ThreadLocal value still
non-null. However, the specific user cannot control all usages of
ThreadLocals: it might be in some third party code, or some Exception
happens in some place where one didn't think of ThreadLocal cleanup (one
doesn't tend to handle ThreadLocals with the same care as closing e.g. a
SQL Connection, and even that isn't always done), or again, it happens
in some third party code, where the ThreadLocal simply isn't available
for cleanupping.
Even "java itself", as noted in a comment for bug 6254531, has lots of
such usage that will lead to leak if loaded by a user classloader.
The key point here, is that the old implementation, a map keyed on
Thread, didn't have this problem. The problem was introduced with the
reimplementation for performance improvement that the 1.3 version came
up with, since now the Thread object itself holds a strong reference to
the value, and ditching all references to all objects, and all classes,
and the classloader, WILL NOT any longer be enough to make sure GC can
happen, since one also will have to let all Threads die, taking the
ThreadLocal value references with them..
This last little point is the sole problem the OP referred to - and I
cannot understand that this isn't an unintended consequence of the
performance improvement reimplementation - it definitely is a regression
compared to how the initial implementation worked, that much I hope
anyone will agree to.
Thomas Hawtin ("Tackline" - see links) has apparently come up with some
solution that will ensure that merely a ThreadLocal reference won't make
the referenced value non GCable, which doesn't degrade performance (much).
Kind regards,
Endre.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Locked
