Managing Data with the ThreadLocal Class

ThreadLocal class allows you to put local data on a thread, so that every module running in the thread can access it. ThreadLocal has been around since JDK 1.2, but hasn't been used much, maybe because of a first, rather poor implementation, performance-wise.


Documentation From ThreadLocal Api
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).

An example may help clarify this concept. A servlet is executed in a thread, but since many users may use the same servlet at the same time, many threads will be running the same servlet code concurrently. If the servlet uses a ThreadLocal object, it can hold data local to each thread. The user ID is a good example of what could be stored in the ThreadLocal object. I like to think of this object as a hash map where a kind of thread ID is used as the key.
ThreadLocal contains these methods:
Method
Purpose
Object get()
Returns the value for the current thread
set(Object)
Sets a new value for the current thread
Object initialValue()
Used to return an initial value (if ThreadLocal is subclassed)
remove()
In JDK 5 only - used to delete the current thread's value (for clean-up only)
The simplest way to use a ThreadLocal object is to implement it as a singleton. Here's an example in which the value stored in the ThreadLocal is a List:

public class MyThreadLocal {

  private static ThreadLocal tLocal = new ThreadLocal();

  public static void set(List list) {
    tLocal.set(list);
  }

  public static List get() {
    return (List) tLocal.get();
  }

makes it simple to set or get the current thread's value:

MyThreadLocal.set(list);
. . .
list = MyThreadLocal.get();

The first time you use this technique, it may seem a bit like magic, but behind the scenes, the local data is simply fetched using a unique ID of the thread.