ThreadLocal with examples in Java

It makes multi-threading easy by not sharing the state of an object across threads. Since state is not shared so you don’t need to synchronize it with other requests. Please be noted that ThreadLocal is not a substitute of synchronization, instead it isolates an object from being exposed to multiple threads. Something like this:

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

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

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

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

ThreadLocal is ideal for storing objects that are not thread-safe and object sharing across threads is not required. A good example is Hibernate Session which is not threadsafe and must not be shared across threads, so we can put Session into ThreadLocal and execute the transaction. In a servlet environment, this can happen in a filter which creates a new session for each request and commit the session after request is complete. Similar approach can be taken for JDBC connection.

SimpleDataFormat is not a thread-safe class, so you can use ThreadLocal to keep a copy of it per thread, thus avoiding the need for synchronization. The other option could be to create a new object on each invocation which requires more resources compared to ThreadLocal approach.

import java.text.SimpleDateFormat;
import java.util.Date;

public class ThreadSafeDateFormat {
    //SimpleDateFormat is not thread-safe, so give one instance to each thread
    private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy.MM.dd HHmm a"));

    public static String formatIt(Date date) {
        return formatter.get().format(date);
    }

    public static void main(String[] args) {
        final String formatIt = ThreadSafeDateFormat.formatIt(new Date());
        System.out.println("formatIt = " + formatIt);
    }
}

ThreadLocal is very useful in web applications, a typical pattern is to store the state of web request in ThreadLocal (usually in a servlet filter or spring interceptor) at the very start of the processing and then access this state from any component involved in request processing. Normally all the processing of a web request happens in a single thread. In-fact ThreadLocal is widely used in implementing application frameworks. For example, J2EE containers associate a transaction context with an executing thread for the duration of an EJB call. This is implemented using a static Thread-Local holding the transaction context.

In creating a application that requires thread level stats collections for e.g. stress testing apps, performance monitoring app.

ThreadLocal introduces hidden coupling among classes, which makes them hard to test and debug. So it should be used with care.

It is easy to abuse ThreadLocal by treating its thread confinement property as a license to use global variables or as a means of creating “hidden” method arguments.

Java Concurrency in Practice: Where author (Joshua Bloch) explains how Thread confinement is one of the simplest ways to achieve thread safety and ThreadLocal is more formal means of maintaining thread confinement.

Discussion on SO - https://stackoverflow.com/questions/817856/when-and-how-should-i-use-a-threadlocal-variable