ThreadLocal; isn't it the same as creating a copy of the variable each time?

Question

Hi,

I am still confused of the concept of ThreadLocal. I have read the JavaDoc, and other related questions posted around here, but the jargons used and all didn't help me much.

I kind of get the idea of ThreadLocal, that is, each thread has its own copy of the variable. So...how does this make it different from say...constructing the new variable everytime?

For example, using DateFormatter as the example:

public void convertDate(String date) 
{ 
    // Contruct new date formatter for every invocation of the method.
    DateFormatter df = new SimpleDateFormatter(...);
    ....
}

public void convertDate(String date) 
{ 
    // Getting date formatter from threadlocal.
    DateFormatter df = threadLocal.get();
    ....
}

How is the first different from the second one if the all the second one does is just returning a new copy of the variable?

Thanks.

Answer 1

ThreadLocal objects are typically static, which means that they preserve their values between function calls within the same thread.

In your first code snippet, every time convertDate is called, a new SimpleDateFormatter object is created. In the second snippet, one SimpleDateFormatter object per thread is created. The same object is returned by the get() method every time convertDate is called within the same thread.

ThreadLocal objects are useful in implementing thread-local storage, which means maintaining separate instances of variables for each thread.

Answer 2

There are a few different uses for ThreadLocal.

As in your example, an expensive to construct, thread-unsafe object can be cached. The object than can then be used in a safe manner without the overhead of construction every use. It's not necessarily a win (more, non-local memory is used, for instance), but it might be.

It can also be used to 'sleaze' through a context argument into a callback that isn't designed to have context. Or just to make interfaces simpler. In this case the canonical reference to the ThreadLocal is probably not static. The object may also be deliberately mutable. I'm not a great fan of encouraging this technique, but some people (such as "crazy" Bob Lee) like it.

ThreadLocal doesn't work so well when you fork tasks off into multiple threads. InheritableThreadLocal appears to have no good uses.

Answer 3

You two examples are the same iff the second method is called in a different thread each time. In which case the first example is more efficient.

If however, you call the same method more than once in the same thread, it will cache the value for that thread and not have to create a new object each time. (Most of the object relating to dates are fairly expensive is which case it can be worth doing) In this case there is a small performance advantage in reusing the same object in a thread.

Note: the thread local objects are storing in a map attached to the Thread itself. If the thread dies, all the objects local to that thread are GCed. This is where ThreadLocal can be simpler than most caches.