ThreadLocal overview: Use actual combat, source code analysis, memory leak analysis

preface

Even if you don’t use ThreadLocal directly, it also appears indirectly in frameworks you use, such as Spring transaction management, Hibernate Session management, logBack (and Log4j) MDC functionality implementation, etc. In project development, for example, some paging functions are implemented with the help of ThreadLocal.

Because of ThreadLocal’s ubiquity, it’s not uncommon to be asked in interviews about its implementation, core API usage, and memory leaks.

And based on these problems can be extended to thread safety, JVM memory management and analysis, Hash algorithm and other knowledge points. You can see how important ThreadLocal is to developers. If you don’t have the full picture, then this article is worth studying in depth.

What is a ThreadLocal

@Test public void test1(){ ThreadLocal<String> localName = new ThreadLocal<>(); // Only one set method is provided; Localname.set (" program new horizon "); // Only one get method is provided. String name = localname.get (); System.out.println(name); }Copy the code

Example ThreadLocal

Given the usage scenarios and basic implementation theory, let’s take a look at how ThreadLocal can be used with a simple example.

Public class ThreadLocalMain {/** * ThreadLocal, each thread has a copy, Public static final ThreadLocal<String> HOLDER = new ThreadLocal<>(); public static void main(String[] args) throws Exception { new ThreadLocalMain().execute(); } public void execute() throws Exception {// Main thread set value holder.set (" program new horizon "); Thread.out.println (thread.currentThread ().getName() + "ThreadLocal:" + holder.get ()); New Thread(() -> {system.out.println (thread.currentThread ().getName()) + "+ holder.get ()); // Set the value holder.set (" Program horizon ") in the current thread; System.out.println(" after reset, "+ Thread.currentThread().getName() +" ThreadLocal: "+ holder.get ()); System.out.println(thread.currentThread ().getName() + "Thread terminated "); }).start(); Thread.sleep(1000L); Thread.out.println (thread.currentThread ().getName() + "ThreadLocal:" + holder.get ()); }}Copy the code

The example defines a static final ThreadLocal variable HOLDER, simulating two threads in the main method to manipulate the values stored in the HOLDER. The HOLDER is set to a value, and the obtained value is printed. A new thread is created to modify the value in the HOLDER, and the corresponding value is fetched from both the new thread and the main thread.

Execute the program and print the following results:

ThreadLocal = null; ThreadLocal = null The value in the main Thread ThreadLocal: the program new horizonCopy the code

Comparing the program with the output, you can see that the main Thread and Thread-0 each have their own variable store. The main Thread is not changed because Thread0 called HOLDER’s set method.

This is possible because in ThreadLocal, each Thread has a copy of its own variable, and multiple threads do not interfere with each other. So how, you might wonder, does ThreadLocal accomplish this?

Analysis of ThreadLocal principle

Basic process and source code implementation

Within a single Thread can save multiple ThreadLocal object, the location of the store is located in the Thread of the ThreadLocal. ThreadLocalMap variables, in the Thread has the following variables:

/* ThreadLocal values pertaining to this thread. This map is maintained
 * by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
Copy the code

ThreadLocalMap is a static inner class maintained by ThreadLocal, as noted in the code note that this variable is maintained by ThreadLocal.

When we use the get() and set() methods of ThreadLocalMap, we actually call the corresponding get() and set() methods of ThreadLocalMap.

This variable in Thread is usually initialized when ThreadLocal’s get() and set() methods are first called.

public void set(T value) { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map ! = null) map.set(this, value); else createMap(t, value); }Copy the code

In the set method above, we get the current thread object first, and then use getMap to get threadLocals from the current thread:

ThreadLocalMap getMap(Thread t) {
    return t.threadLocals;
}
Copy the code

If the corresponding attribute in Thread is null, create a ThreadLocalMap and assign it to Thread:

void createMap(Thread t, T firstValue) {
    t.threadLocals = new ThreadLocalMap(this, firstValue);
}
Copy the code

If it already exists, set the value using the set method of ThreadLocalMap. Here we can see that the set key is this, which is the current ThreadLocal object, and the value is the value we want to store.

The corresponding get method source is as follows:

public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map ! = null) { ThreadLocalMap.Entry e = map.getEntry(this); if (e ! = null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }Copy the code

As you can see, also from the current thread, get the threadLocals property of the current thread and return the stored value from it. During get, if the threadLocals property of the Thread is not initialized, the createMap method is indirectly called to initialize the Thread.

Let’s summarize the above processes through a flow chart:

In JDK8 and 9, the createMap method is not used to initialize the Thread locals property. It is not clear how the JVM performs the initialization assignment. When testing JDK13 and JDK14, the createMap method was obviously used.

Data structure of ThreadLoalMap

static class ThreadLocalMap { static class Entry extends WeakReference<ThreadLocal<? >> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<? > k, Object v) { super(k); value = v; } } private static final int INITIAL_CAPACITY = 16; / /... }Copy the code

ThreadLocalMap(ThreadLocal<? > firstKey, Object firstValue) { table = new Entry[INITIAL_CAPACITY]; int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); }Copy the code

Hash conflict and resolution

Note that in the constructor the Entry location in the table is obtained using the Hashcode algorithm. Each ThreadLocal object has a hash value of threadLocalHashCode, and each time a ThreadLocal object is initialized, the hash value increases by a fixed size 0x61C88647.

When an Entry object is stored into an Entry value in a ThreadLocalMap, it is positioned to position I in the table based on the hash value of the ThreadLocal object. There are three cases:

• If the current location is empty, the Entry is directly stored in the corresponding location.
• If position I already has a value and the key of the Entry object happens to be the key to be set, then reset the value in the Entry.
• If the Entry object of position I is unrelated to the key to be set, look for an empty position;

Hash conflicts occur when calculating hash values. Common solutions include rehash, open address, public overflow area, and chained address.

The above process can be seen here is open address method, if the current position value, will continue to look for the next position, pay attention to the table [len – 1] is the next position table [0], like a circular array, so also called closed hashing. If you can’t find the empty space all the time, an infinite loop will occur, and memory will overflow. Of course, there is a mechanism to expand capacity, won’t find empty position commonly.

ThreadLocal memory leaks

Memory reference link

According to the previous analysis of ThreadLocal, each Thread maintains a ThreadLocalMap, whose key is the ThreadLocal instance itself and value is the Object that services need to store. That is, ThreadLocal does not store values itself; it simply acts as a key for the thread to retrieve values from ThreadLocalMap.

Take a close look at the ThreadLocalMap, which uses a weak reference to ThreadLocal as its Key, and the weakly referenced object is reclaimed during GC. So with ThreadLocal, the chain of references looks like this:

Dashed lines indicate weak references. Let’s start by looking at the classification of references in Java.

References in Java

Cause analysis of leakage

Normally, threads are destroyed when they are finished executing, and the ThreadLocalMap instance pointed to by Thread.threadlocals becomes garbage and the Entity stored in it is reclaimed. There is no memory leak in this case.

The memory leak scenario usually exists in the case of thread pools. In this case, the Thread life cycle is long, and the threadLocals reference will always exist. When the ThreadLocal stored in it is reclaimed (the weak reference life cycle is short), the Entity will become an instance with a null key, but the value will not be reclaimed. If the Entity is never get(), set(), or remove(), it is never reclaimed and a memory leak occurs.

Therefore, the remove() method is usually called after ThreadLocal is used to clean up memory.

For example, in a Web request, we can call the recycle method through filters and so on:

Public void doFilter(ServeletRequest Request, ServletResponse){try{// Set ThreadLocal localname.set (" new view "); Chain. DoFilter (request, response)}finally{// Call remove to overflow the localname.remove () variable in threadLocal; }}Copy the code

Why weak references instead of strong references?

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys. WeakReference is used as a key in hash table entries to help deal with scenarios with large data and long life cycle.Copy the code

Application scenario of ThreadLocal

Finally, let’s review the application scenario of ThreadLocal:

• Data isolation between threads, ThreadLocal of each thread does not affect each other;
• Convenient for the same thread to use a certain object, avoid unnecessary parameter passing;
• ThreadLocal is generally used for traceId in full link tracing or context transfer in process engine.
• The Spring transaction manager uses ThreadLocal;
• The implementation of Spring MVC’s RequestContextHolder uses ThreadLocal;

summary

The interview series

• Interview questions: Talk about TCP sticky, unpack, and Solutions
• Interview question: Why does overriding equals usually override hashCode?
• Interviewer: How to find the longest string in a string without repetition?
• Don’t Understand Java generics? Just use this article to make sure you have a good interview answer.
• Interview Question: 8 Ways to Invert a string. What can you Think of?

Program new horizon

\

The public account “program new vision”, a platform for simultaneous improvement of soft power and hard technology, provides massive information

\