ThreadLocal

Last modified on October 11th, 2014 by Joe.

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.

Table of Contents

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.



Example for ThreadLocal

package com.javapapers; import java.text.SimpleDateFormat; import java.util.Date; public class ThreadLocalExample { private static final ThreadLocal formatter = new ThreadLocal() { protected SimpleDateFormat initialValue() { return new SimpleDateFormat("yyyyMMdd HHmm"); } }; public String formatIt(Date date) { return formatter.get().format(date); } }

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.

import java.util.concurrent.atomic.AtomicInteger; public class ThreadId { // Atomic integer containing the next thread ID to be assigned private static final AtomicInteger nextId = new AtomicInteger(0); // Thread local variable containing each thread's ID private static final ThreadLocal threadId = new ThreadLocal() { @Override protected Integer initialValue() { return nextId.getAndIncrement(); } }; // Returns the current thread's unique ID, assigning it if necessary public static int get() { return threadId.get(); } }

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.

Following is the code that implements ThreadLocal in the above class:

private static final ThreadLocal localRandom = new ThreadLocal() { protected ThreadLocalRandom initialValue() { return new ThreadLocalRandom(); } };

Example using ThreadLocalRandom

package com.javapapers; import java.util.concurrent.ThreadLocalRandom; public class ThreadLocalRandomExample { public static void main(String args[]) throws InterruptedException { //tossing 3 coins for (int i = 0; i < 3; i++) { final Thread thread = new Thread() { public void run() { System.out.print(Thread.currentThread().getName() + ":"); // generating 3 random numbers - random for every thread for (int j = 0; j < 3; j++) { final int random = ThreadLocalRandom.current().nextInt( 1, 3); System.out.print(random + ","); } System.out.println(); } }; thread.start(); thread.join(); } } }

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!

I wish to quote Joshua Bloch,

"...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