1

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
Community
  • 1
  • 1
Ajay
  • 7,378
  • 18
  • 57
  • 75

3 Answers3

1

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.

Gregory Mostizky
  • 7,231
  • 1
  • 26
  • 29
  • "whatever data you put in there stays there as long as the thread lives unless it is explicitly removed" this doesn't seem to be the case (at least with 1.6.0_26); Javadoc says "as long as the thread is alive and the ThreadLocal instance is accessible" and a test program I wrote indicates that the thing in the ThreadLocal can be collected when the ThreadLocal becomes inaccessible. – Samuel Edwin Ward May 25 '12 at 19:34
0
  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.

kdgregory
  • 38,754
  • 10
  • 77
  • 102
  • Why is SimpleDateFormat said to be costly in terms of construction? – Ajay Sep 29 '09 at 12:00
  • Are you asking about ThreadLocal or are you asking about SimpleDateFormat? If you want to understand the latter, look at its source code (available in JAVA_HOME/src.zip), and compare its constructor to, say, StringBuilder. – kdgregory Sep 29 '09 at 12:31
  • You have mentioned " high cost of construction (such as SimpleDateFormat)" in your answer. It would be helpful if you can justify as to how it is costly in terms of construction – Ajay Sep 29 '09 at 12:44
0

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.

yawn
  • 8,014
  • 7
  • 29
  • 34