Java Thread Local Storage explained in easiest practical way

Java Thread Local Storage

One of the cool feature of Java that I like is ThreadLocal storage. ThreadLocal storage is explained in easiest way with practical example in this blog.

ThreadLocal is a class in java.lang package which provides a way to store and access data of any type per thread, which means each thread will have it's separate instance of the data. During execution of a thread, one class can set data in ThreadLocal and other classes further down in the execution layer can access/read the data, as long as execution in within same thread. It is important to know that ThreadLocal data set by one thread is not visible or accessible in another thread. That the core concept of ThreadLocal storage.

The way to use ThreadLocal is declare a static property of type ThreadLocal where T is type of the data we want to store. It's static so that it easily accessible in classes wherever needed. You can declare it public, private or whatever make sense in your usecase. Usually declaring it as public make sense.

Since the way ThreadLocal storage works, it must be used carefully. To avoid incorrect use of ThreadLocal by mistake, it is good idea to declare ThreadLocal variables in a separate class and name the class appropriate to call it out load.

Once declared you can set data into ThreadLocal variable
AppThreadLocal.USER_CONTEXT.set(userContext);
And to read data from ThreadLocal variable
UserContext userContext = AppThreadLocal.USER_CONTEXT.get();
Lets see the practical use of ThreadLocal variable. Use case is in practical when we write service API, we need the UserContext (calling user's userId, name, may roles as well) available in all layer's (API, Service, Facade, DAO etc). One way to make UserContext available in all these layers is to pass UserContext as parameter in all methods starting from top to the bottom most layer, which sounds like over kill and cluttering you method signature. ThreadLocal is best fit in such situation. At the first layer we can put UserContext in a public static ThreadLocal variable, access and it in all layer's further down during execution, once execution is done, remove it from ThreadLocal.

Lets see how does the code look like to implement this.

UserContext is the class whose instance we want to store in ThreadLocal Storage
The class where we defined ThreadLocal variable
The Thread which sets UserContext in ThreadLocal variable, calls service api (where UserContext will be read from ThreadLocal) and once done remove data from ThreadLocal variable.
Its the service class which reads UserContext from ThreadLocal and just print it. If this calls further calls Facade or DAO, UserContext can be read there in exact same way.
Finaly the main program. It creates 2 different UserContext instances, creates two threads and pass each UserContext to them and start both threads.
In the output you can see that service method executed by tommy-Thread is getting Tom's UserContext and service method executed by jerry-Thread is getting Jerry's UserContext.

 

Note - 

It is important to remove data from ThreadLocal specially in case if your code is running under a managed container like Application Server. Because containers usually implement thread pool to process request, after processing the thread is release back to thread pool and will be used to processed other upcoming requests. Which means data set in ThreadLocal variable by first request will be available to other requests processed by same thread. Which is not correct. Also if the data put into ThreadLocal is big in size, it may lead to memory leak because thread will always remain alive in the pool and data object in ThreadLocal plus any other objects referenced by it will never become eligible for garbage collection.

The power comes will responsibility so always use ThreadLocal responsibly to avoid trouble.

Download Code

https://github.com/rakeshprajapati1982/thread-local

It you found this blog helpful please share. Any question or comments are always welcome.



Comments

Post a Comment

Other Popular Posts

How to enable JPA eclipselink logging in WAS Liberty

Image
When this goes well, you are happy but every developer hits situation when you need more logs and details to troubleshoot issue and determine root case. It happens many times when you work with JPA and thing don't goes as you expect. You really need to look under the hood what JPA is going, what SQL statements it's generating and executing. Environment: WAS Liberty 17.0.01, JAVA EE 7, JPA 2.1, EclipseLink 2.6.3 In above environment, to enable JPA logging including SQL statements, bind parameters and transaction details do following - Add following tow properties in persistence.xml <property name="eclipselink.logging.level" value="ALL"/> <property name="eclipselink.logging.parameters" value="true"/> Add following logging tag in server.xml <logging traceSpecification="eclipselink=all" maxFileSize="20" maxFiles="10"/> Redeploy application and recycle server. All done! T
Read more

EhCache3 as JCache (JSR-107) Implementation with Cache Statistics

Image
If you are reading this you already know that caching is mechanism to store static data In-Memory for faster access and avoid expensive database calls or any kind of service calls to get the data. Read my other post to learn InMemory Caching using EhCache3 . There are many ways to implement cache in java based applications, starting from very simple Map based caching to Apache Common JCS , EhCache , Apache Ignite , Hazelcast , Oracle Coherence and many more. With so many implementations available, question is which one we should go for?  If you have to choose one from multiple options best bet is to look for standard. Standard because many people have put their mind together in it, better support, examples and guide available for reference plus expect that further upgrades/changes will not breaking changes. So for InMemory cache Standard Specification is JSR-107 .  You can read about it in more detail at JSR 107: JCACHE - Java Temporary Caching API . JCache specifies API
Read more

Lambda Expression v/s Anonymous Inner Class - Java 8

Image
Lambda Expression is new feature of Java 8. Before Java 8 Anonymous Inner Class was very useful to provide method local implementation of any interface like ActionListner or EventListener etc. With Java 8 if the interface is a Functional Interface we can use Lambda Expression to provide implementation. Both of these can implement an Interface but there are subtle differences between them. Following are to the point differences between them - Anonymous Inner class can implement any interface but Lambda can implement only Functional Interface , the interface with only one abstract method. Anonymous Inner Class can have state variables but Lambda Expression cannot. Lambda Expression is stateless. Lambda Expression can only access final or effectively final variables of containing method. Scope - Anonymous Inner Class creates a new scope whereas Lambda Expression does not. Lambda executes always within scope of surrounding context. To explain it better, in Anonymous Inner Clas
Read more

EhCache3 In Memory Caching for Performance Improvement

Image
If you are reading this you already know that caching is mechanism to store static data In-Memory for faster access and avoid expensive database calls or any kind of service calls to get the data. There are many ways to implement cache in java based applications, starting from very simple Map based caching to Apache Common JCS , EhCache , Apache Ignite , Hazelcast , Oracle Coherence and many more. Each of them have pros and cons. I will show how to use EhCache for caching implementation EhCache3 Implementation For this example you need to have following jars in the class path - <dependency> <groupId>org.ehcache</groupId> <artifactId>ehcache</artifactId> <version>3.4.0</version> </dependency> <dependency> <!-- We need this because ehcache uses slf4j for logging --> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version>
Read more