Purpose of ThreadLocal?

Question

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.

View more solutions

Comments

[Ajay]

Deliberately associated with each thread meaning?. The thread itself is an object right? So associated with a thread in fact means associated with the thread Object?

[Stephen C]

@Ajay: Yes. ThreadLocal instances are associated with Thread objects via semi-private data structures attached to the Thread objects; see the "package private" members Thread.threadLocals and Thread.inherittableThreadLocals

[Ajay]

@Stephen: So what difference does it make in having a threadLocal as compared to having a member of a Thread Class.

[Ajay]

What is StaticClass here?. The class that extends Thread?

[leonm]

StaticClass is just a handy way of getting hold of the ThreadLocal object. I'll edit the example to include the code for StaticClass.

[Michael Borgwardt]

An instance of a Thread subclass is no different from any other object, and its members can be accessed by any and all threads.

[Rich Seller]

I wouldn't say it is always more elegant, but it is more expedient

[Daksh Gargas]

So will this object gets shared across multiple threads?