My First Encounter With ThreadLocal
- Problem: Find an efficient way to share dynamic configurable values in an application, without restarting the application.
- Solution: Use ThreadLocal.
At first, I have thought about loading the config values into system memory or the application context during the start-up phrase. However, if I need to change the values, then I would need to restart the application.
Then, I think about reading these values from properties files or from database every time when I need to use it. But that is very inefficient.
Well, ThreadLocal seems to be prefect for this type of jobs.
FAQs of ThreadLocal
- What is the benefit of using ThreadLocal?
An easier thread-safe way to manage shared variables in a thread-scope (sort of like web session-scope/request-scope) without explicitly passing the variables in method signature. - Why not that many people know about ThreadLocal?
Well, many developers do know about ThreadLocal, since it has been introduced in Java 1.2. However, not that many use it because of the performance issue of using it in Java 1.2. Nevertheless, the performance of ThreadLocal has gradually improved in each newer version of Java. - What is a thread-local variable?
Each thread that accesses a thread-local variable (via the get or set method) has its own, independently initialized copy of the variable. - Synchronize vs. ThreadLocal
For safely sharing the access to certain objects (resources/variables), using ThreadLocal or synchronizing the objects are both fine. However, such objects are usually more expensive to create than to use. One good example would be JDBC connection. Furthermore, this is why pooling might not be a better solution than using ThreadLocal, especially when pool implementations must synchronize the pool data structure to maintain integrity. - What about memory leak issue with ThreadLocal?
When a thread is terminated, all of its ThreadLocal instances are subject to be cleaned by garbage collection, unless other references to these copies exist. Also, please be aware that some application platforms/environments use a Thread pool. That is, the thread might never die, and the ThreadLocal instances would stay in memory and would not go away. Therefore, it is always a good practice that when you no longer need these ThreadLocal instances, please set them to null or call the remove() method. - Static and ThreadLocal
In Java, ThreadLocal is a class, and static is a modifier that can be used on variables, methods, and classes. Making a ThreadLocal variable static and private is a way to ensure the variable’s integrity per-thread. - Volatile and ThreadLocal
Volatile is a modifier that defines the way on how a variable be accessed and stored in memory. And, it is generally ignored by most JVM implementation. ThreadLocal is a class, which provides a mechanism on how to share data among different modules/classes/instances in a single thread. It has nothing to do with memory access requirement. - Would each child thread need to call the initialValue() or set() method, even it just needs to read same ThreadLocal variable from the parent?
In that scenario, please use the subclass InheritableThreadLocal. Furthermore, if the goal is to read, then use the ThreadLocal or InheritableThreadLocal for immutable objects only. Also, with InheritableThreadLocal, the data is now shared with multiple threads, therefore, stateful objects like JDBC connections should not be declared as InheritableThreadLocal.
Other Resources
- Java doc on ThreadLocal
- Threading lightly, Part 3: Sometimes it’s best not to share Exploiting ThreadLocal to enhance scalability.
- Managing Data with the ThreadLocal Class
- Java Thread Local – How to Use and Code Sample
