ThreadLocal

Core concept of ThreadLocal is, “every thread that accesses a ThreadLocal variable via its get or set method has its own, independently initialized copy of the variable”. In this tutorial we will learn about ThreadLocal.

ThreadLocal Introduction

We want to have separate instances(private copy) of a class so that there will not be any conflict among multiple threads. Each instance will be unique for each thread. This is nothing but a way of implementing threadsafety.

An important point about ThreadLocal variable is the global access. It can be accessed from anywhere inside the thread. Also note that, it is declared static and final.

What is threadsafe?

A thread is a single line of process. When we refer multi-threaded applications, we mean that there mulitple (sequential flow of control) line of process that runs through the same lines of code. In such situation, there is a possibility of one sequence(thread) accessing/modifying data of other sequence(thread). When data cannot be shared like this, then we make it threadsafe. Following are the some of the different ways of implementing threadsafe operation:

Re-entrancy

Mutual exclusion (synchronization)

Thread-local

Atomic operation

So, in the above list Thread-local is one option. Hope now we get how ThreadLocal fits in the cube.

Uses of ThreadLocal

I cannot resist but quote Joshua Bloch (who better I can choose for this section),
in his own words:

Genuine per-thread context, such as user id or transaction id. Works great. Easy to clean up when the thread exits the scope. No leaks.

Per-thread instances for performance.

“Sleazing” values through callbacks that you don’t control: sometimes you must call a library method that calls back into your package. At this point, you need some context that you were unable to pass to yourself, due to deficiencies in the library. In this rare situation, thread locals can be a lifesaver.

Above points, in my own terms: We have an object that is not threadsafe and we want to use it safely. We go for synchronization by enclosing that object in synchronized block. Other way around is using ThreadSafe, what it does is holds separate instance for each thread and makes it safe.

In the above sample code, get() method is key to understanding. It returns the value in the current thread’s copy of this thread-local variable. If the variable has no value for the current thread, it is first initialized to the value returned by an invocation of the initialValue method.

Example from javadoc

The class below generates unique identifiers local to each thread. A thread’s id is assigned the first time it invokes ThreadId.get() and remains unchanged on subsequent calls.

Use of ThreadLocal in Java API

In JDK 1.7 we have got a new class namely ThreadLocalRandom. It can be used to generate random numbers specific to parallel threads. Seed for random number will be unique for each thread. This is a real cool utility.

ThreadLocal and Memory Leaks

ThreadLocal is not evil, it is a nice utility API. It all depends on how we use it. We should learn to choose the right tool for the right situation. We cannot use cannons to burst mosquitoes, but do not blame the cannons.

There are strong complaints all over the web saying ThreadLocals will cause memory leaks. 'Mostly' No!

"...There is nothing inherently wrong with thread locals: They do not cause memory leaks. They are not slow. They are more local than their non-thread-local counterparts (i.e., they have better information hiding properties). They can be misused, of course, but so can most other programming tools...."

Why 'Mostly' No? - In case of 'self-referential structures', there is a memory leak. Refer the bug_id 6254531

Can you explain what is difference between using Thread Local and Synchronization. You neither focus on when to use Thread Local or when to use synchronization.
Moreover when we have synchronization, why should we use Thread Local.

The article is quite confusing which talks only about the behavior of the local threads accessing its own stack of values.

As per my suggestions, the article should include the output of the given code as well. Also, threading concepts should be elaborated enough to get the right picture of multithreading concepts as well.

Great article!
One thing I’d like to see is if you could explain when the ThreadLocal object can/needs to be set. That is, before the threads are created, after threads are created, but before the ‘start/run’ is called, or after threads are created and ‘start/run’ is called.

ThreadLocal variable in Java can create serious memory leaks if it is used to store instances of classes which is loaded by a classloader other than BootStrapClassLoader. For example, stroing Java API classes on ThreadLocal will not cause memory leak in web application, but application class, which is loaded by web-app classloader will.