Some questions about ThreadLocal

[lightning]

In javadoc:
Each thread holds an implicit reference to its copy of a thread-local
variable as long as the thread is alive and the ThreadLocal instance
is accessible; after a thread goes away, all of its copies of thread-
local instances are subject to garbage collection (unless other
references to these copies exist).


It seems only when thread "goes away",the threadlocals of that thread
will be cleaned.
But what about when using threadpools?
For example:
Executors.newFixedThreadPool()


In TOMCAT,the threadlocals works fine because framework such dwr ,
struts2 or spring transactionmanager using threadlocals to store many
things.How did it work?
Will it work fine no matter no matter Tomcat is using threadpool or
using singlethread mode?

 

[Mark Space]

In TOMCAT,the threadlocals works fine because framework such dwr ,
struts2 or spring transactionmanager using threadlocals to store many
things.How did it work?

I'm not sure what you are trying to say. Can you give some code as an
example?

Regardless, I'm pretty sure that if a thread completes, it cannot be
used again. Therefore I assume that Executors such as FixedThreadPool
have some way of keeping a thread "open" and alive, and not allowing it
to terminate. So ThreadLocal objects should persist.

Will it work fine no matter no matter Tomcat is using threadpool or
using singlethread mode?

Single threaded mode is best avoided under all circumstances. Just
don't use it. I have no idea what it might do to thread local objects
under the various Java EE containers.

 

[Kevin McMurtrie]

I'm not sure what you are trying to say. Can you give some code as an
example?

Regardless, I'm pretty sure that if a thread completes, it cannot be
used again. Therefore I assume that Executors such as FixedThreadPool
have some way of keeping a thread "open" and alive, and not allowing it
to terminate. So ThreadLocal objects should persist.

ThreadLocal's storage has a WeakReference to the Thread as a key. That
means that the key lasts exactly as long as the Thread object, never
longer or shorter. The thread pointer could be re-used at the OS-level
but that's OK because it's guaranteed that no old Java references exist.

ThreadLocal should only be used as a last resort. It's prone to causing
mysterious side-effects and memory bloating. If you must use one, put
just one at a very high level and use it to store a session manager.

 

[shortcutter]

Same here, the question - if any - is not clear to me. ThreadLocals
can of course be used in the presence of thread pools. You just have
to be aware of the fact that their life time may exceed that of the
current "request" (whatever that is in a particular application).

ThreadLocal's storage has a WeakReference to the Thread as a key.

This is not true. The weak reference points to the ThreadLocal
instance in order to make an entry garbage collectible when the
ThreadLocal instance can be collectible. The map itself is a member
of Thread so this is collected if the Thread is collected.

 That
means that the key lasts exactly as long as the Thread object, never
longer or shorter.

The key can (and most likely will in the case of a static ThreadLocal)
last longer than a thread.

ThreadLocal should only be used as a last resort.  It's prone to causing
mysterious side-effects and memory bloating.

I would agree saying that you should be knowing what you are doing.
But I would not necessarily say this is a "last resort" only. It all
depends. It's a tool like many others with advantages and
disadvantages.

 If you must use one, put
just one at a very high level and use it to store a session manager.

The benefit of this session manager being?

Cheers

robert