On 5/27/2012 3:04 PM, Mike Schilling wrote:
"Daniel Pitts"<newsgroup.nospam@virtualinfinity.net> wrote in
message news:8Euwr.47425$On2.20024@newsfe16.iad...
On 5/27/12 11:00 AM, Mike Schilling wrote:
"markspace"<-@.> wrote in message
news:jptkmp$vbg$1@dont-email.me...
On 5/26/2012 4:11 PM, Mike Schilling wrote:
Proposed feature: a static method on Thread that clears all
ThreadLocals
for
the current thread.
I can see your points. However, I don't have any real
experience with ThreadLocal, and when a neophyte agrees with
your argument, that's a red
flag.
Here's a blog where someone seems to have the same issue as you.
<http://weblogs.java.net/blog/jjviana/archive/2010/06/10/threadlocal-thread-pool-bad-idea-or-dealing-apparent-glassfish-memor>
At the end of the comments, there's a suggestion to use
ThreadLocal::remove(), with the implication that it allows the
thread local variable to be garbage collection. Is there a
reason that doesn't
work for you?
That acts on an individual ThreadLocal (and works quite well),
but it doens't allow removing all ThreadLocals that might have
been accumlated.
You're basically saying "This type of resource can leak if not
cleared appropriately, so there should be a 'Release all
resources' method." When paraphrased that way, does that make it
clearer why it isn't
a good idea? It would be about the same as a "File.closeAll()" or
a "Socket.closeAll()" call. Extremely dangerous and only a
crutch for not doing the right thing to begin with.
Or a "collect all unused memory" call . Clearly, that's a crutch
for not keeping track of memory allocation properly in the first
place. And the fact that files and sockets are closed when a
process exits is yet another
crutch.
I'm with Daniel. Your code uses classes that you wrote, and
classes you got from somewhere else -- Sioux Unusuals, perhaps.
And if those classes use ThreadLocals for their own purposes, and
you blithely destroy them all, what happens then? Or what about
the class that invoked your code, passing an InheritableThreadLocal?
Is it a good idea to change parts of your invoker's state that you
don't understand, that you aren't even aware of?