ThreadLocal implementation

Question

With reference to my earlier question, going a bit further,

1. What are the disadvantages of using ThreadLocals as opposed to local variables
2. How are they implemented
3. Are session variables ThreadLocals
4. Are there more examples of ThreadLocals used frequently

Answer 1

1. Disadvantages as compared to what?
2. As a Map<Thread,Value> -- it's actually a map attached to the thread, but easier to think about as a map keyed by thread
3. No
4. ThreadLocals are very infrequently used, and should remain that way

In my opinion, the only reason for an application developer to use ThreadLocal is if s/he needs to make frequent use of a non-threadsafe utility object that has a (relatively) high cost of construction (such as SimpleDateFormat). And even then, it's a tossup.

Answer 2

I am not sure I would call it a disadvantage but one must be really careful with cleaning up ThreadLocals properly since whatever data you put in there stays there as long as the thread lives unless it is explicitly removed. This is especially troublesome in an environment where the threads are reused using thread pools so some garbage data maybe attached to thread unless it's cleaned properly.

ThreadLocals are used a lot actually - mainly by framework developers as they allow attaching "context" to user methods without changing method signature. Transaction management in J2EE for example is done with ThreadLocals - the reference to current open transaction is always attached to the thread so that when you work with database you will automatically access it using the currently open transaction. Without ThreadLocal you would need to pass those references as method parameters.

There are many additional examples of such usage. I am not sure what session variables you are referring to but session-like data is often attached to ThreadLocal.

Regarding implementation - I am not sure really. I think I read somewhere that it is implemented inside JVM on fairly low level to make the performance very fast since quite a lot of code uses it today.

Answer 3

A real life example: the AMQP messaging protocol allows for several multiplexed logical connections (called channels) to co-exist in one e.g. TCP/IP connection. Since some operations change the state of the logical connection it is desirable to model concurrent messaging operations as operations on concurrent channels. When your concurrency model is threaded you can do this very easily by encapsulating channel access with a ThreadLocal get() and the opening a channel with a initialValue() override.

In the context of the Spring framework you can use thread-local beans transparently using appropriate target sources.