ThreadLocal Kills 11 consecutive questions

Preface

Some time ago , There are colleagues using

ThreadLocal

Step on the pit , It just caught my interest .

So recently , I'll take the time to ThreadLocal Study the source code of , The more you look, the more interesting it is , I found a lot of things in it .

I condensed the essence , The collection is integrated into the following 11 A question , See how many you can withstand ？

1.  Why use ThreadLocal?

Concurrent programming is a very important technology , It makes our program more efficient .

But in a concurrent scenario , If there are multiple threads modifying public variables at the same time , There may be thread safety issues , That is, the final result of this variable may be abnormal .

In order to solve the thread safety problem ,

JDK

There are many technical means , such as ： Use

synchronized

or

Lock

, Lock code that accesses public resources , It ensures the of the code

Atomicity

.

But in high concurrency scenarios , If multiple threads compete for a lock at the same time , There will be a lot of lock waiting , It may waste a lot of time , Make the response time of the system slow down .

therefore ,

JDK

It also provides another new idea of exchanging space for time ：

ThreadLocal

.

Its core idea is ： Shared variables in each

Threads

There is one.

copy

, Each thread operates on its own copy , No effect on other threads .

for example ：

@Service
public class ThreadLocalService {
 private static final ThreadLocal<Integer> threadLocal = new ThreadLocal<>();

 public void add() {
 threadLocal.set(1);
 doSamething();
 Integer integer = threadLocal.get();
 }
}


2. ThreadLocal What is the principle of ？

To find out ThreadLocal The underlying implementation principle of , We have to pick up the source code .

ThreadLocal

There is a static inner class called ：

ThreadLocalMap

.

public class ThreadLocal<T> {
 ...
 public T get() {
 // Get the current thread
 Thread t = Thread.currentThread();
 // Get the member variables of the current thread ThreadLocalMap object
 ThreadLocalMap map = getMap(t);
 if (map != null) {
 // according to threadLocal Objects from map In order to get Entry object
 ThreadLocalMap.Entry e = map.getEntry(this);
 if (e != null) {
 @SuppressWarnings(&quot;unchecked&quot;)
 // Get saved data
 T result = (T)e.value;
 return result;
 }
 }
 // Initialization data
 return setInitialValue();
 }
 
 private T setInitialValue() {
 // Get the data to initialize
 T value = initialValue();
 // Get the current thread
 Thread t = Thread.currentThread();
 // Get the member variables of the current thread ThreadLocalMap object
 ThreadLocalMap map = getMap(t);
 // If map Not empty
 if (map != null)
 // Set the initial value to map in ,key yes this, namely threadLocal object ,value Is the initial value
 map.set(this, value);
 else
 // If map It's empty , You need to create a new map object
 createMap(t, value);
 return value;
 }
 
 public void set(T value) {
 // Get the current thread
 Thread t = Thread.currentThread();
 // Get the member variables of the current thread ThreadLocalMap object
 ThreadLocalMap map = getMap(t);
 // If map Not empty
 if (map != null)
 // Set the value to map in ,key yes this, namely threadLocal object ,value It's incoming value value
 map.set(this, value);
 else
 // If map It's empty , You need to create a new map object
 createMap(t, value);
 }
 
 static class ThreadLocalMap {
 ...
 }
 ...
}


ThreadLocal

Of

get

Method 、

set

Methods and

setInitialValue

Method , In fact, the final operation is

ThreadLocalMap

Data in class .

among

ThreadLocalMap

The interior of the class is as follows ：

static class ThreadLocalMap {
 static class Entry extends WeakReference<ThreadLocal<?>> {
 Object value;

 Entry(ThreadLocal<?> k, Object v) {
 super(k);
 value = v;
 }
 }
 ...
 private Entry[] table;
 ...
}


ThreadLocalMap

It contains a static inner class

Entry

, This class inherits from

WeakReference

class , explain

Entry

Is a weak reference .

ThreadLocalMap

It also contains a

Entry

Array , among ：

Entry

 = 

ThreadLocal

 + 

value

.

and

ThreadLocalMap

Defined as

Thread

Member variables of class .

public class Thread implements Runnable {
 ...
 ThreadLocal.ThreadLocalMap threadLocals = null;
}


Let's use a picture from the macro view , Get acquainted. ThreadLocal Overall structure ：

As you can see from the picture above , At every

Thread

Class , There is one.

ThreadLocalMap

Member variables of , This variable contains a

Entry Array

, This array really holds ThreadLocal class set The data of .

Entry

By threadLocal and value form , among threadLocal Object is a weak reference , stay

GC

When , Will be automatically recycled . and value Namely ThreadLocal class set The data of .

Here is a diagram to summarize the reference relationship ：

Except for Entry Of key Yes ThreadLocal The object is

Weak reference

, Other references are

Strong citation

.

One thing to note is that , Above picture ThreadLocal I painted the object on the pile , In fact, in the actual business scenario, it is not necessarily on the heap . Because if ThreadLocal Defined as static Of ,ThreadLocal Objects are shared by classes , It may appear in the method area .

3.  Why ThreadLocal do key？

I wonder if you have ever thought about such a problem ：

ThreadLocalMap

Why use

ThreadLocal

do key, Rather than using

Thread

do key？

If in your application , Only one... Is used in a thread

ThreadLocal

object , So use

Thread

do key Not too bad .

@Service
public class ThreadLocalService {
 private static final ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
} 


But in reality , Your application , There is a good chance that more than one thread is used ThreadLocal object . Use this time

Thread

do key No, there's a problem ？

@Service
public class ThreadLocalService {
 private static final ThreadLocal<Integer> threadLocal1 = new ThreadLocal<>();
 private static final ThreadLocal<Integer> threadLocal2 = new ThreadLocal<>();
 private static final ThreadLocal<Integer> threadLocal3 = new ThreadLocal<>();
} 


If used

Thread

do key when , Your code defines 3 individual ThreadLocal object , that , adopt Thread object , How does it know which to get ThreadLocal What about objects? ？

As shown in the figure below ：

therefore , Out of commission

Thread

do key, Instead, use

ThreadLocal

Object to do key, In this way, we can pass the specific ThreadLocal Object's

get

Method , Easily get what you want ThreadLocal object .

As shown in the figure below ：

4. Entry Of key Why is it designed as a weak reference ？

As I said before ,Entry Of key, What's coming in is ThreadLocal object , Used

WeakReference

object , That is, it is designed as a weak reference .

that , Why is it designed like this ？

If key Yes ThreadLocal Weak references to objects , Change to strong reference .

We all know ThreadLocal Variable pair ThreadLocal Objects have strong references .

Even if ThreadLocal The variable life cycle is over , Set to null 了 , But because of key Yes ThreadLocal Or strong reference .

here , If the code is executed

Threads

Used

Thread pool

, It's been around for a long time , Will not be destroyed .

There will be such

Strong reference chain

：Thread Variable  -> Thread object  -> ThreadLocalMap -> Entry -> key -> ThreadLocal object .

that ,ThreadLocal Objects and ThreadLocalMap Will not be

GC

Recycling , So there was

Memory leak

problem .

To solve this problem ,JDK Our developers put Entry Of key It's designed to be

Weak reference

.

Weak reference

The object of , stay GC When doing garbage cleaning , Will be automatically recycled .

If key Is a weak reference , When ThreadLocal Variable pointing to the null after , stay GC When doing garbage cleaning ,key Will be automatically recycled , Its value is also set to null.

As shown in the figure below ：

Next , Here comes the key point .

Due to the current ThreadLocal The variable has been pointed to

null

了 , But if you call it directly

get

、

set

or

remove

Method , Obviously there will be

Null pointer exception

. Because its life is over , It doesn't make sense to call its method again .

here , If another... Is defined in the system ThreadLocal Variable b, It's called

get

、

set

or

remove

, Any of the three methods , Will automatically trigger the cleaning mechanism , take key by null Of value Value clear .

If key and value All are null, that Entry The object will be GC Recycling . If all Entry Objects are recycled ,ThreadLocalMap Will also be recycled .

In this way, we can solve

Memory leak

problem .

What needs special attention is ：

• key by null Is the condition of ,ThreadLocal Variable pointing to the
  null
  , also key Is a weak reference . If ThreadLocal The variable is not disconnected ThreadLocal A strong reference to , namely ThreadLocal The variable does not point to null,GC Just rashly quote the weak key Recycled , No, it will affect the use of normal users ？

• If at present ThreadLocal Variable pointing to the
  null
  了 , also key Also for the null 了 , But if nothing else ThreadLocal Variable trigger
  get
  、
  set
  or
  remove
  Method , It can also cause memory leaks .

Let's take a look at the example of weak reference ：

public static void main(String[] args) {
 WeakReference<Object> weakReference0 = new WeakReference<>(new Object());
 System.out.println(weakReference0.get());
 System.gc();
 System.out.println(weakReference0.get());
}


Print the results ：

[email protected]
null


Pass in WeakReference The construction method is direct new Objects to be processed , There are no other quotes , Calling gc After the method , Weakly referenced objects are automatically recycled .

But if this happens ：

public static void main(String[] args) {
 Object object = new Object();
 WeakReference<Object> weakReference1 = new WeakReference<>(object);
 System.out.println(weakReference1.get());
 System.gc();
 System.out.println(weakReference1.get());
}


Execution results ：

[email protected]
[email protected]


First define a strong reference object object , stay WeakReference In the construction method object The reference of the object is passed in as a parameter . At this time , call gc after , Weakly referenced objects are not automatically recycled .

our Entry Object key Isn't that the second case ？ stay Entry What is passed in the construction method is ThreadLocal References to objects .

If you will object The strong reference is set to null：

public static void main(String[] args) {
 Object object = new Object();
 WeakReference<Object> weakReference1 = new WeakReference<>(object);
 System.out.println(weakReference1.get());
 System.gc();
 System.out.println(weakReference1.get());

 object=null;
 System.gc();
 System.out.println(weakReference1.get());
}


Execution results ：

[email protected]
[email protected]
null


The second time gc after , Weak references can be recycled normally .

thus it can be seen , If a strong reference and a weak reference are associated with an object at the same time , Then this object will not be GC Recycling . In other words, in this case Entry Of key, Never for null, Unless a strong reference actively disconnects the Association .

Besides , You may also ask such a question ：

Entry Of value Why not design it as a weak reference ？

answer ：Entry Of value If only Entry quote , It may not be referenced elsewhere in the business system . If you will value Changed to weak reference , By GC Hastily recycled （ The data suddenly disappeared ）, It may lead to business system exceptions .

And by contrast ,Entry Of key, The place of management is very clear .

This is it. Entry Of key Designed as a weak reference , and value The reason why it is not designed as a weak reference .

5. ThreadLocal It will really lead to memory leakage ？

Through the top Entry Object key Set to weak reference , And use

get

、

set

or

remove

Methods to clean up key by null Of value value , Can completely solve the memory leak problem ？

The answer is No .

As shown in the figure below ：

If ThreadLocalMap There's a lot of key by null Of Entry, But the later procedure , I haven't called a valid ThreadLocal Of

get

、

set

or

remove

Method .

that ,Entry Of value The value has never been cleared .

So there will be such a

Strong reference chain

：Thread Variable  -> Thread object  -> ThreadLocalMap -> Entry -> value -> Object.

The result is ：Entry and ThreadLocalMap Will last for a long time , It can lead to

Memory leak

.

6.  How to solve the memory leak problem ？

As I said before ThreadLocal It will still lead to the problem of memory leakage , Do we have a solution ？

answer ： Is there a way to , call ThreadLocal Object's

remove

Method .

Not calling... From the beginning remove Method , But after using ThreadLocal After object . Columns such as ：

So let's create one CurrentUser class , Which includes ThreadLocal The logic of .

public class CurrentUser {
 private static final ThreadLocal<UserInfo> THREA_LOCAL = new ThreadLocal();
 
 public static void set(UserInfo userInfo) {
 THREA_LOCAL.set(userInfo);
 }
 
 public static UserInfo get() {
 THREA_LOCAL.get();
 }
 
 public static void remove() {
 THREA_LOCAL.remove();
 }
}


Then call the relevant methods in the business code ：

public void doSamething(UserDto userDto) {
 UserInfo userInfo = convert(userDto);
 
 try{
 CurrentUser.set(userInfo);
 ...
 
 // Business code
 UserInfo userInfo = CurrentUser.get();
 ...
 } finally {
 CurrentUser.remove();
 }
}


What needs our special attention is ： Must be in

finally

Block of code , call

remove

Methods to clean up useless data . If the business code is abnormal , It can also clean up useless data in time .

remove

The method will put Entry Medium key and value Set up null, So it can be GC Timely recovery , There is no need to trigger additional cleaning mechanisms , So it can solve the problem of memory leakage .

7. ThreadLocal How to locate the data ？

As I said before ThreadLocalMap The bottom layer of the object is Entry Arrays hold data .

So here comes the question ,ThreadLocal How to locate Entry Array data ？

stay ThreadLocal Of get、set、remove Method has such a line of code ：

int i = key.threadLocalHashCode & (len-1);


adopt key Of hashCode value ,

And

The length of the array minus 1. among key Namely ThreadLocal object ,

And

The length of the array minus 1, It's equivalent to dividing by the length of the array minus 1, then

modulus

.

This is a kind of hash Algorithm .

Next, let me give you an example ： hypothesis len=16,key.threadLocalHashCode=31,

therefore ： int i = 31 & 15 = 15

amount to ：int i = 31 % 16 = 15

The result of the calculation is the same , But use

And operation

Be more efficient .

Why is it more efficient ？

answer ： because ThreadLocal The initial size of is

16

, Press... Every time

2

Double expansion , The size of the array has always been 2 Of n Power . There is a rule of this kind of data, that is, the high level is 0, The low posts are 1. When doing and operations , You don't have to consider the high position , Because the result of the and operation must be 0. Just consider the low order and operation , So it's more efficient .

If you use hash If the algorithm locates the specific location , It could happen

hash Conflict

The situation of , Two different hashCode The value after taking the mold is the same .

ThreadLocal Is how to solve hash What about the conflict ？

Let's see.

getEntry

How it's done ：

private Entry getEntry(ThreadLocal<?> key) {
 // adopt hash The algorithm obtains the subscript value
 int i = key.threadLocalHashCode & (table.length - 1);
 Entry e = table[i];
 // If at the subscript position key Just what we need to find key
 if (e != null && e.get() == key)
 // That means we found the data , Go straight back to
 return e;
 else
 // Explain the appearance of hash The conflict , Keep looking back
 return getEntryAfterMiss(key, i, e);
}


I want to see others

getEntryAfterMiss

Method ：

private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
 Entry[] tab = table;
 int len = tab.length;

 // Judge Entry If the object is not empty , And it's going through the cycle
 while (e != null) {
 ThreadLocal<?> k = e.get();
 // If at present Entry Of key Just what we need to find key
 if (k == key)
 // It shows that we really found the data this time
 return e;
 if (k == null)
 // If key It's empty , Clean up dirty data
 expungeStaleEntry(i);
 else
 // If you still don't find the data , Then continue to look back
 i = nextIndex(i, len);
 e = tab[i];
 }
 return null;
}


Key look

nextIndex

Method ：

private static int nextIndex(int i, int len) {
 return ((i + 1 < len) ? i + 1 : 0);
}


When passed hash The index calculated by the algorithm is less than the size of the array , Then add the subscript value 1. otherwise , That is, the subscript is greater than or equal to the size of the array , The subscript becomes 0 了 . The subscript becomes 0 after , Then cycle once , The subscript becomes 1...

The general process of searching is shown in the figure below ：

If you find the last one , Still can't find , Then start looking for .

I don't know if you noticed , It constitutes a ：

ring

.

ThreadLocal The process of finding data from an array is roughly like this ：

• adopt key Of hashCode Take the remainder and calculate a subscript .

• By subscript , Locate the concrete in the array Entry, If key Just what we need key, It means that , Then directly return the data .

• If the first 2 We didn't find the data we wanted , From the subscript position of the array , Keep looking back .

• If the first 3 Find in step key It's just what we need key, It means that , Then directly return the data .

• If you still don't find the data , Then continue to look behind . If you find the last position , Still no data found , Then start again , That is, the subscript is 0 The location of , Continue looking for data from front to back .

• Until we find the first Entry Until it's empty .

8. ThreadLocal How to expand capacity ？

Learn from the above ,ThreadLocal The initial size of is

16

. So here comes the question ,ThreadLocal How to expand capacity ？

stay

set

Method is called

rehash

Method ：

private void set(ThreadLocal<?> key, Object value) {
 Entry[] tab = table;
 int len = tab.length;
 int i = key.threadLocalHashCode & (len-1);

 for (Entry e = tab[i];
 e != null;
 e = tab[i = nextIndex(i, len)]) {
 ThreadLocal<?> k = e.get();

 if (k == key) {
 e.value = value;
 return;
 }

 if (k == null) {
 replaceStaleEntry(key, value, i);
 return;
 }
 }

 tab[i] = new Entry(key, value);
 int sz = ++size;
 if (!cleanSomeSlots(i, sz) && sz >= threshold)
 rehash();
}


Pay attention to the , One of the criteria is ：sz( Previous size+1) If it is greater than or equal to threshold Words , Call rehash Method .

threshold The default is 0, Creating ThreadLocalMap when , Call its constructor ：

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);
}


call setThreshold Methods threshold Set a value , And this is worth INITIAL_CAPACITY Is the default size 16.

private void setThreshold(int len) {
 threshold = len * 2 / 3;
}


That's what was set for the first time threshold = 16 * 2 / 3,  The rounded value is ：10.

In other words, when sz Greater than or equal to 10 when , We can consider expanding the capacity .

rehash The code is as follows ：

private void rehash() {
 // Try recycling first key by null Value , Make room
 expungeStaleEntries();

 if (size >= threshold - threshold / 4)
 resize();
}


Before the real expansion , Try recycling first key by null Value , Make room .

If after recycling size Greater than or equal to threshold Of 3/4 when , Just need real expansion .

The calculation formula is as follows ：

16 * 2 * 4 / 3 * 4 - 16 * 2 / 3 * 4 = 8


That is, after adding data , new size Older than or equal to size Of

1/2

when , Just need to expand .

private void resize() {
 Entry[] oldTab = table;
 int oldLen = oldTab.length;
 // Press 2 Times the size of the expansion
 int newLen = oldLen * 2;
 Entry[] newTab = new Entry[newLen];
 int count = 0;

 for (int j = 0; j < oldLen; ++j) {
 Entry e = oldTab[j];
 if (e != null) {
 ThreadLocal<?> k = e.get();
 if (k == null) {
 e.value = null; // Help the GC
 } else {
 int h = k.threadLocalHashCode & (newLen - 1);
 while (newTab[h] != null)
 h = nextIndex(h, newLen);
 newTab[h] = e;
 count++;
 }
 }
 }

 setThreshold(newLen);
 size = count;
 table = newTab;
}


resize Press... Every time 2 Times the size of the expansion .

The process of capacity expansion is shown in the figure below ：

The key steps of capacity expansion are as follows ：

• The old size + 1 =  new size

• If new size Older than or equal to size Of 2/3 when , Expansion needs to be considered .

• Try to recycle before capacity expansion key by null Value , Make room .

• If it is found after recycling size Or greater than or equal to the old size Of 1/2 when , Just need real expansion .

• Press... Every time 2 Times the size of the expansion .

9.  How parent and child threads share data ？

Previously introduced ThreadLocal It's all in

One thread

To save and obtain data in .

But in practice , It is possible to share data in parent-child threads . That is, in the parent thread ThreadLocal Set the value , In the sub thread, you can get .

for example ：

public class ThreadLocalTest {

 public static void main(String[] args) {
 ThreadLocal<Integer> threadLocal = new ThreadLocal<>();
 threadLocal.set(6);
 System.out.println(&quot; The parent thread gets data ：&quot; + threadLocal.get());

 new Thread(() -> {
 System.out.println(&quot; The child thread gets the data ：&quot; + threadLocal.get());
 }).start();
 }
}


Execution results ：

The parent thread gets data ：6
The child thread gets the data ：null


You'll find that , Use in this case ThreadLocal It doesn't work .main The method is executed in the main thread , Equivalent to parent thread . stay main Method opens another thread , Equivalent to a child thread .

Obviously through ThreadLocal, Cannot share data between parent and child threads .

that , What to do ？

answer ： Use

InheritableThreadLocal

, It is JDK Own class , Inherited ThreadLocal class .

After modifying the code ：

public class ThreadLocalTest {

 public static void main(String[] args) {
 InheritableThreadLocal<Integer> threadLocal = new InheritableThreadLocal<>();
 threadLocal.set(6);
 System.out.println(&quot; The parent thread gets data ：&quot; + threadLocal.get());

 new Thread(() -> {
 System.out.println(&quot; The child thread gets the data ：&quot; + threadLocal.get());
 }).start();
 }
}


Execution results ：

The parent thread gets data ：6
The child thread gets the data ：6


Sure enough , In exchange for InheritableThreadLocal after , The value set in the parent thread can be normally obtained in the child thread .

Actually , stay Thread In addition to member variables threadLocals outside , There is another member variable ：inheritableThreadLocals.

Thread Part of the code for the class is as follows ：

ThreadLocal.ThreadLocalMap threadLocals = null;
ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;


The key point is , In its

init

Method will send the parent thread to ThreadLocal Set the value of the , Copy a copy to the child thread .

Interested partners , You can talk to me in private . Or take a look at my later article , There will be a column later .

10.  How to share data in the thread pool ？

In a real business scenario , Rarely used

Separate threads

, most , It's all for

Thread pool

.

that , How to share in the thread pool ThreadLocal The data generated by the object ？

Because different threads are involved , If used directly ThreadLocal, Clearly not appropriate .

We should use InheritableThreadLocal, The specific code is as follows ：

private static void fun1() {
 InheritableThreadLocal<Integer> threadLocal = new InheritableThreadLocal<>();
 threadLocal.set(6);
 System.out.println(&quot; The parent thread gets data ：&quot; + threadLocal.get());

 ExecutorService executorService = Executors.newSingleThreadExecutor();

 threadLocal.set(6);
 executorService.submit(() -> {
 System.out.println(&quot; Get data from thread pool for the first time ：&quot; + threadLocal.get());
 });

 threadLocal.set(7);
 executorService.submit(() -> {
 System.out.println(&quot; Get data from the thread pool for the second time ：&quot; + threadLocal.get());
 });
}


Execution results ：

The parent thread gets data ：6
Get data from thread pool for the first time ：6
Get data from the thread pool for the second time ：6


Because the singleton thread pool is used in this example , The number of fixed threads is 1.

for the first time submit During the mission , This thread pool will automatically create a thread . Because of the use of InheritableThreadLocal, So when creating a thread , Will call it init Method , The... In the parent thread inheritableThreadLocals Copy data to child threads . So we see , Set to main data in the main thread 6, Get the correct data from the thread pool for the first time 6.

after , In the main thread, the data is changed to 7, But getting data from the thread pool for the second time is still 6.

Because the second time submit During the mission , There is already a thread in the thread pool , Just bring it directly , No more threads will be recreated . So I won't call the thread again init Method , So the second time I didn't get the latest data 7, Or the old data obtained 6.

that , What should I do ？

answer ： Use

TransmittableThreadLocal

, It's not JDK Own class , But Alibaba open source jar The class in the package .

It can be done by pom Import this file jar package ：

<dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>transmittable-thread-local</artifactId>
 <version>2.11.0</version>
 <scope>compile</scope>
</dependency>


The code is adjusted as follows ：

private static void fun2() throws Exception {
 TransmittableThreadLocal<Integer> threadLocal = new TransmittableThreadLocal<>();
 threadLocal.set(6);
 System.out.println(&quot; The parent thread gets data ：&quot; + threadLocal.get());

 ExecutorService ttlExecutorService = TtlExecutors.getTtlExecutorService(Executors.newFixedThreadPool(1));

 threadLocal.set(6);
 ttlExecutorService.submit(() -> {
 System.out.println(&quot; Get data from thread pool for the first time ：&quot; + threadLocal.get());
 });

 threadLocal.set(7);
 ttlExecutorService.submit(() -> {
 System.out.println(&quot; Get data from the thread pool for the second time ：&quot; + threadLocal.get());
 });

}


Execution results ：

The parent thread gets data ：6
Get data from thread pool for the first time ：6
Get data from the thread pool for the second time ：7


We see , Used TransmittableThreadLocal after , The second time, the latest data can be correctly obtained from the thread 7 了 .

nice.

If you look closely at this example , You might notice , In addition to using

TransmittableThreadLocal

Outside class , Also used.

TtlExecutors.getTtlExecutorService

Method , To create

ExecutorService

object .

This is a very important place , If there is no such step ,

TransmittableThreadLocal

Sharing data in the thread pool will not work .

establish

ExecutorService

object , At the bottom submit Method Society

TtlRunnable

or

TtlCallable

object .

With TtlRunnable Class, for example , It has achieved

Runnable

Interface , At the same time, it also realizes its run Method ：

public void run() {
 Map<TransmittableThreadLocal<?>, Object> copied = (Map)this.copiedRef.get();
 if (copied != null && (!this.releaseTtlValueReferenceAfterRun || this.copiedRef.compareAndSet(copied, (Object)null))) {
 Map backup = TransmittableThreadLocal.backupAndSetToCopied(copied);

 try {
 this.runnable.run();
 } finally {
 TransmittableThreadLocal.restoreBackup(backup);
 }
 } else {
 throw new IllegalStateException(&quot;TTL value reference is released after run!&quot;);
 }
}


The main logic of this code is as follows ：

• Put the ThreadLocal Make a backup , Then the parent class's ThreadLocal Copy it over .

• Carry out the real run Method , You can get the latest of the parent class ThreadLocal data .

• From the backed up data , Restore the ThreadLocal data .

11. ThreadLocal What are the USES ？

Last , Let's talk ThreadLocal What are the USES ？

honestly , Use ThreadLocal There are many scenes .

Here are some common scenarios ：

• stay spring Transaction , Ensure that one thread , Multiple operations of a transaction get one Connection.

• stay hiberate In the management session.

• stay JDK8 Before , In order to solve SimpleDateFormat Thread safety of .

• Get the context of the currently logged in user .

• Temporarily save permission data .

• Use MDC Save log information .

wait , There are many business scenarios , Here is not a list .

Due to limited space , Today's content is shared here . I hope you read this article , There will be gains .

Next, leave a few questions for everyone to think about ：

• ThreadLocal Why is the variable suggested to be defined as static Of ？

• Entry Why do arrays pass hash The algorithm calculates the subscript , Straight line addressing method , Instead of using subscript values directly ？

• What's the difference between strong references and weak references ？

• Entry Array size , Why 2 Of N Power ？

• Use InheritableThreadLocal when , If the parent thread re set value , Can the modified new value be obtained correctly in the sub thread ？

Please look forward to my next article , thank you .