Purpose of ThreadLocal? [duplicate]

The purpose of ThreadLocal as given here states that the variable is local to any Thread accessing an object containing the ThreadLocal variable. What difference does it make, in having a ThreadLocal variable as a member of a class and then making it local to a Thread, rather than having a local variable to the Thread itself?

Solution 1:

A thread is a unit of execution and so multiple thread can execute the same code at the same time. If multiple threads execute on an object/instance at the same time they will share the instance variables. Each thread will have its own local variables but it is difficult to share these across objects without passing parameters.

It is best explained by way of an example. Say you have a Servlet that gets the logged in user and then executes some code.

doGet(HttpServletRequest req, HttpServletResponse resp) {
  User user = getLoggedInUser(req);
  doSomething()
  doSomethingElse()
  renderResponse(resp)
}

Now what happens if the doSomething() methods needs access to the user object? You can't make the user object an instance or static variable because each thread will then use the same user object. You could pass the user object around as a parameter but this quickly becomes messy and leaks user objects into every method call:

doGet(HttpServletRequest req, HttpServletResponse resp) {
  User user = getLoggedInUser(req);
  doSomething(user)
  doSomethingElse(user)
  renderResponse(resp,user)
}

A more elegant solution is to put the user object into a ThreadLocal

doGet(HttpServletRequest req, HttpServletResponse resp) {
  User user = getLoggedInUser(req);
  StaticClass.getThreadLocal().set(user)
  try {
    doSomething()
    doSomethingElse()
    renderResponse(resp)
  }
  finally {
    StaticClass.getThreadLocal().remove()
  }
}

Now any code that requires the user object at any time can get hold of it by extracting it from the thread local, without needing to resort to those pesky extra parameters:

User user = StaticClass.getThreadLocal().get()

If you use this approach be mindful to remove the objects again in a finally block. Otherwise the user object might hang around in environments that use a Thread Pool (like Tomcat app server).

Edit: The code for static class

class StaticClass {
  static private ThreadLocal<User> threadLocal = new ThreadLocal<>();

  static ThreadLocal<User> getThreadLocal() {
    return threadLocal;
  }
}

Solution 2:

You have to realize that an instance of a class that extends Thread is not the same thing as an actual Java thread (which can be imagined as a "execution pointer" that runs through your code and executes it).

Instances of such a class represent a Java thread and allow to manipulate it (e.g. interrupt it), but apart from that they are just regular objects, and their members can be accessed from all threads that can get hold of a reference to the object (which is not hard).

Of course you can try to keep a member private and make sure that it's only used by the run() or methods called from it (public methods can be called from other threads as well), but this is error-prone and not really feasible for a more complex system where you don't want to keep data all in a Thread subclass (actually you're not supposed to subclass Thread, but to use Runnable instead).

ThreadLocal is a simple, flexible way to have per-thread data that cannot be accessed concurrently by other threads, without requiring great effort or design compromises.

Solution 3:

A Thread object can have internal data members but these are accessible to anyone who has (or can get) a reference to the Thread object. A ThreadLocal is deliberately associated only with the each Thread that accesses it. The advantage is that there are no concurrency issues (within the context of the ThreadLocal). A Thread's internal data member has all the same concurrency issues any shared state does.

Let me explain the idea of associating a result with a particular thread. The essence of a ThreadLocal is something like this:

public class MyLocal<T> {
  private final Map<Thread, T> values = new HashMap<Thread, T>();

  public T get() {
    return values.get(Thread.currentThread());
  }

  public void set(T t) {
    values.put(Thread.currentThread(), t);
  }
}

Now there's more to it than that but as you can see the value returned is determined by the current thread. That's why it's local to each thread.

Solution 4:

ThreadLocal is very useful in webapplications. The typical pattern is that somewhere at the start of the processing of a web request (usually in a servlet filter) state is stored in a ThreadLocal variable. Because all of the processing for a request is done in 1 thread all components participating in the request have access to this variable.

Solution 5:

There is a wikipedia entry about this problem area. In our environment it's usually used to keep things local to request. On the server side a request is handled mostly by a single thread. To keep things local you put your data, e.g. the session data, in a thread local variable. This data is invisible to the other request (threads) and therefore you don't need to synchronize it with the other requests.

And donn't forget, there are JAVA API constructs, that are not thread safe, e.g. DateFormat. A static instance of DateFormat just doesn't work on the server side.

In fact, it's easier to handle multi threaded programming when you use your own private copy of data than handling with locks and monitors.