ThreadLocal detailed explanation, ThreadLocal source code analysis, ThreadLocal diagram

This article is about:

Concept explanation ----- principle illustration ----- source code analysis ----- thought arrangement ----- other supplements.

1、 Concept elaboration.

ThreadLocal is a tool class to solve the data security problem in multi-threaded concurrency scenarios. It can make the use of member variables safe in multi-threaded environment.

When using ThreadLocal, each thread gets its own set value after setting the value on ThreadLocal. In the case of concurrency, the stored values and values between threads do not affect each other.

In fact, the name of ThreadLocal is not appropriate. If it is named according to its function and function, it should be called threadlocalvariable, that is, thread local variable. Let's analyze it in detail below.

2、 Principle diagram

First, we introduce an example. Our usual use of ThreadLocal is similar to the following pseudo code.

In this pseudo code, we only need to call set (x) to set the value and get () to get the value. This context is a shared variable.

In general, shared variables are not safe, so why is ThreadLocal safe? How to ensure that the data will not go wrong?

OK, the above figure shows:

In the figure above, we first look at the left side of the red line. The figure on the left shows the internal implementation of ThreadLocal. The right side shows the relationship diagram of objects in memory when using.

As can be seen from the figure on the left, ThreadLocal has an internal class threadlocalmap, which is actually used to store data. The thread class has a threadlocalmap member variable.

Looking at the example code and graphic display on the left of the red line, we can see that the data follows the thread, and the value set by the thread is tied with a rope and held in your hand. So the data string is not.

If you don't understand, it doesn't matter. After all, you haven't seen the specific code implementation. Take this picture as an appetizer first, and then eat the code.

3、 Source code analysis

3.1. ThreadLocal source code comments.

Rough translation:

Why can ThreadLocal realize the independent values of each thread's access operation? How is it implemented? I'm going to see how it accesses from the set and get methods.

3.2 how to set values?

The ThreadLocal stored value method, i.e. set method, is implemented as follows:

When a thread calls the set method of ThreadLocal instance.

The first line first obtains the thread t that currently calls set.

The second line calls the getmap (T) method according to the thread t to find the threadlocalmap corresponding to the current thread. This map is actually a member variable of thread t. As can be seen from the code implementation:

In the if judgment at the beginning of the third line, if there is a threadlocalmap, call the set method to insert the key value pair composed of < current ThreadLocal instance and current set value > into the threadlocalmap.

If the corresponding threadlocalmap cannot be obtained, it is created. (the threadlocalmap here is actually a data structure that can store key value pairs. It is analyzed below.)

createMap方法代码如下：

3.3 how to get values?

How to get values? How to put the elephant in the refrigerator, how to take the elephant out of the refrigerator, right?

Before looking at the get code implementation, first recall how the previous set method stores values:

1. Get the current thread.

2. Get the local variable threadlocalmap of the current thread

3. Put the current ThreadLocal instance and the current "elephant" into the threadlocalmap.

4. Complete.

Therefore, the value taking method should be the opposite of it, that is, "change the save in step 3 to take". Let's see if the code is written like this?

The value obtaining method is as follows:

Sure enough, that's what we analyzed.

3.4 arrangement of ideas

In order to store a data, three concepts are involved: ThreadLocal, threadlocalmap and thread.

It seems a little messy. Here's how to sort it out:

Suppose there is a ThreadLocal instance called beautiful girl. At present, there are two threads T1 and T2 that want to keep their chromosomes Y1 and Y2 to beautiful girl (you know)

In fact, Y1 and Y2 are placed in two threadlocalmap instances. T1 and T2 respectively hold a respective map instance MAP1, MAP2, Y1 and Y2 in their hands.

When T1 wants to get his Y1 back, find the beautiful girl and ask him to put his hand into MAP1 to take Y1 out. This is actually the principle.

You can combine this explanation and look back at the diagram and code.

Friends who understand may ask: don't you say that the map is an entry [] array? Here, T1 just puts its own Y1 in, and there is no need for an array. Just an object. actually:

One day, T1 encountered another ThreadLocal instance, beautiful Girl2. T1 was so excited that it called beautiful Girl2 Set (x1) method gives its chromosome X1 to beautiful girl 2 for safekeeping. Thus, the MAP1 in T1's hand has two values. That's why maps are designed as arrays. So that T1 and T2 can send out X and Y chromosomes for preservation. this is it:

3.5. What is threadlocalmap.

Through the above set method tracking, it can be found that threadlocalmap is a static internal class of ThreadLocal. The comments of this class are as follows: