[concurrency-interest] reusing threads and thread local state

Joshua Bloch jbloch at gmail.com
Fri Apr 29 17:55:11 EDT 2005


Oh no, not again. I fought this so many times over the years.  It's
one of those ideas that seems good on the surface but isn't.  My
analogy is used cars vs. new cars.  If you want a new car / thread,
you have have to pay a bit more for it.  If you go to a used car lot /
thread pool, the car may have a few dings on it / thread may have a
bit of state associated with it.  If you can live with this, buy a
used car / use a thread pool.  If not, buy a new car / create a

Also, resetting ThreadLocal state does not produce a virgin thread. 
There is other hidden state associated with a thread.  Some of it can
be external to the thread (e.g., it can be registered in a static data
structure). With threads as with people, you can only be a virgin
once.  Yow, are we mixing meaphors yet?

Java has a powerful access control model.  It lets you write provably
correct programs.  Letting one thread muck with another's ThreadLocal
variables eats into this access model.  Just say no.

       My 2 cents,


On 4/29/05, Pete Soper <Pete.Soper at sun.com> wrote:
> Hi,
> An RFE was recently submitted to Sun with this description:
> "Threads are often reused rather than destroyed and recreated, e.g. in a
> Thread pooled server. In that case, it would be nice, even necessary, to
> be able to clear out all ThreadLocalS that were set during the previous
> use of the Thread so that the Thread is reset to its first-created
> state. This could be a clearThreadLocals() method on a Thread instance
> or a static clearAll() method on ThreadLocal class.
> When a Thread is reused by a framework the intent is for it to be as if
> the Thread were just created. ThreadLocalS should not be left over from
> the previous use of the Thread.
> Whether or not this type of Thread reuse is a good idea or not, it is in
> wide use and Java should provide a way to accommodate this usage.
> The only partial workaround is to manually keep track of all
> ThreadLocals used and set them to null or remove them at the end of the
> Thread use. This is obviously not optimal, and in many cases, not
> possible. "
> I'd like to poll this list with the following questions to start some
> informal discussion:
>    - Is this as attractive as it seems? That is, isn't it just a recipe
> for memory leaks? Or perhaps I'm too cautious to think user's might tend
> to overlook persistent references to local objects being part of their
> responsibilty? Tracking references would seem to make tracking the
> locals themselves the easy part in some cases. Or perhaps I'm
> misinterpreting the behavior expected. Perhaps others read this as "go
> find the references and null them out too"?
>    - Are Java implementations obligated to accurately track locals
> associated with a given thread?  I haven't read the specs carefully to
> look for this detail but nothing related to this has jumped out at me.
> It looks like this could be painful for an implementation taking a
> completely different approach to implementing ThreadLocal vs
> InheritedThreadLocal.Or maybe that's bogus thinking. Maybe the
> requirements implicit with InheritedThreadLocal make the ability to
> track the general population of per-thread locals. Thoughts?
>    - Why not Thread.firstCreatedState()? That is, is a focus on local
> state too narrow? I can't think of much state beyond the locals that
> would be relevant (but I've only been thinking about threads for two
> weeks and most of that has been silly stuff like "I need *what* to build
>   J2SE on Windows??" Apologies in advance for the ignorance I will
> surely betray).
>    - The suggested static method seems problematic. For example, it
> would be frustrating when you'd like it to operate on almost all the
> threads, or more likely, the threads you are aware of but no others. Is
> there some reason why it shouldn't be rejected out of hand?
> -Pete
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list