As is known to all, concurrency problems tend to occur when multiple threads access the same static variable, especially when multiple threads write to a variable. In order to ensure thread safety, ordinary users need to carry out additional synchronization measures when accessing shared variables to ensure thread safety. ThreadLocal is an alternative to locking. It implements a mechanism that makes a copy of a static variable, with each thread accessing only one copy, avoiding direct manipulation of race variables and eliminating concurrency problems. So how does ThreadLocal work? Let’s take the veil off ThreadLocal with a piece of code.
ThreadLocal fundamentals
public class ThreadLocalDemo { public static ThreadLocal<String> threadLocal = new ThreadLocal<String>(); public static void main(String[] args) { ThreadLocalDemo.threadLocal.set("hello world main"); Thread.out.println (" thread.currentThread ().getName() + "threadLocal: " + ThreadLocalDemo.threadLocal.get()); try { Thread thread = new Thread() { @Override public void run() { ThreadLocalDemo.threadLocal.set("new thread"); System. The out. Println (" new Thread "+ Thread. CurrentThread (). The getName () +" threadlocal character value is: "+ ThreadLocalDemo. Threadlocal. The get ()); }}; thread.start(); thread.join(); } catch (Exception e) { System.out.println(e); } system.out.println (thread.currentThread ().getName() + "threadLocal"); " + ThreadLocalDemo.threadLocal.get()); }}Copy the codeThe logic of the code is simple: Create a new thread in the main thread and change the threadLocal character value to “new Thread” in the run method of the new thread. The main thread then prints the threadLocal character value again. To ensure that the new thread prints the value of threadLocal before the main thread prints the second time, the join method is used to force the new thread to “block” the main thread until the new thread completes the run method and the main thread continues printing. The result is as follows:
As a result, the new thread does not change the character value of the main thread’s threadLocal, even if the threadLocal type is static. The threadLocal that the new thread modifs is a copy of the threadLocal of the main thread. Let’s source code line by line analysis to get to know, at first we see the first line of code in the main method: first ThreadLocalDemo. ThreadLocal. Set (” hello world main “); Click on the set method and the source code is as follows:
/** * Sets the current thread's copy of this thread-local variable * to the specified value. Most subclasses will have no need to * override this method, relying solely on the {@link #initialValue} * method to set the values of thread-locals. * * @param value the value to be stored in the current thread's copy of * this thread-local. */ 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 codeThere is a class called ThreadLocalMap, and an instance of this class is obtained by a method called getMap(t), which stores the address of the threadLocal variable as the key and the character value as value in the map. If the map is empty, createMap(t,value) will be called to create a map.
/**
* Create the map associated with a ThreadLocal. Overridden in
* InheritableThreadLocal.
*
* @param t the current thread
* @param firstValue value for the initial entry of the map
*/
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
Copy the codeThreadLocals Thread class is a static member variables, it is the type of the Thread of a static inner class ThreadLocalMap, as shown in the following: ThreadLocal. ThreadLocalMap threadLocals = null;
To summarize the above steps, we use a diagram. When the program starts, the code is executed:public static ThreadLocal<String> threadLocal = new ThreadLocal<String>();At this point, the overall stack memory and heap memory are shown in the following figure:
ThreadLocalDemo.threadLocal.set("hello world main");This procedure creates a new Instance of ThreadLocalMap, whose key points to the ThreadLocal object, value is “Hello World main”, and whose key is a weak reference, as shown below:
ThreadLocalDemo.threadLocal.set("new thread");Therefore, two objects will be created in heap memory, one is Thread object, representing the new Thread; One is an instance of Thread’s ThreadLoaclMap, as shown below:
Why weak references
We know that Java references are divided into four types: strong, soft, weak, and virtual. The definition of weak references is that if an object is referred to by only one weak reference, it must be collected by the garbage collector when the next GC comes. ThreadLocalMap:
static class Entry extends WeakReference<ThreadLocal<? >> { /** The value associated with this ThreadLocal. */ Object value; Entry(ThreadLocal<? > k, Object v) { super(k); value = v; }}Copy the codeWe observe that ThreadLocalMap’s key inherits weak references. Why? Light combined with the definition of certainly can not be deeply understood, let us combine the diagram to analyze. Again, assume that the two dotted lines are not weak references, but strong references, as shown in the red line below:
ThreadLocalDemo.threadLocal = null;
That we take the initiative to release the ThreadLocalDemo. ThreadLocal references in the two threads, the results shown in the figure below:
Ever used ThreadLocal?
Yes, in the early days when distributed locking was not implemented by Redission and distributed locking was still implemented by Jedis, we put RedisLockService into the Spring container. This service encapsulates the method of locking and unlocking. If a service is a singleton, it needs to be unlocked by a ThreadLocal thread. If a service is a singleton, it needs to be unlocked by a ThreadLocal thread. If a service is a singleton, it needs to be unlocked by a ThreadLocal thread. During unlocking, check whether the UUID obtained from redis is the same as that of the current thread only when they are the same.