Shulou(Shulou.com)06/02 Report--

What this article shares to you is about the analysis of the principle of ThreadLocal and its application scenario. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

1. What is ThreadLocal? What are the uses?

First introduce the property threadLocals in the Thread class:

/ * ThreadLocal values pertaining to this thread. This map is maintained * by the ThreadLocal class. , /

ThreadLocal.ThreadLocalMap threadLocals = null

We found that Thread does not provide the method of setting and accessing the member variable threadLocals, so how do we operate the instance threadLocals parameter of each thread? Then our protagonist, ThreadLocal, made his debut.

So there is a summary: ThreadLocal is the manager of the attribute threadLocals in the thread Thread.

In other words, the results of our get and set,remove operations for ThreadLocal are all threadLocals save, fetch, and delete operations for the current thread Thread instance. Similar to a developer's task, the product manager can't control it. The product manager can only assign tasks to developers through the technical leader. Here is a chestnut to further illustrate the relationship between them:

1. Everyone has a bank card.

two。 Everyone has a certain balance on each card.

3. Everyone must go through the bank's management system to get the balance of the bank card.

4. Everyone can only get the balance information held by their own card, and others can't access it.

Mapped to what we're going to call ThreadLocal.

1.card is similar to Thread

2.card balance attribute, card number attribute, etc., are similar to Treadlocal internal attribute collection threadLocals

3.cardManager is similar to the ThreadLocal management class

What are the application scenarios of ThreadLocal?

In fact, we have unwittingly been using the convenience provided by ThreadLocal all the time, if you are unfamiliar with the switching of multiple data sources, then the declarative transactions provided by spring are all too familiar, we are using them all the time in the process of research and development, and the important basis for the implementation of spring declarative transactions is ThreadLocal, but we have not studied in depth the implementation mechanism of spring declarative transactions. Later, I will introduce to you the principle and implementation mechanism of spring declarative transactions.

It turns out that ThreadLocal is so powerful, but less used by application developers, and some developers are afraid to try out ThreadLocal memory leaks and other potential problems. I'm afraid this is the biggest misunderstanding of ThreadLocal. Later, we will analyze it in detail. As long as it is used correctly, there will be no problem. If there is a problem with ThreadLocal, isn't it true that spring declarative transactions are the biggest potential danger to our program?

How to use 2.ThreadLocal

In order to more intuitively understand the use of ThreadLocal, let's assume the following scenario

1. We generate an ID for each thread.

two。 Once set, it cannot be changed during the thread life cycle.

3. Duplicate ID cannot be generated during container activity

Let's create a ThreadLocal management class:

The test procedure is as follows: we keep get the same thread to test whether the id has changed, and we will release it when the test is complete.

In the main program, we start multiple threads to test whether the impassable threads will affect each other.

Unsurprisingly, our results are:

The result: it is true that the id is different between different threads, and the same thread has the same id.

3.ThreadLocal principle ① ThreadLocal class structure and method analysis:

As can be seen in the figure above: ThreadLocal has three methods get, set, remove and inner class `ThreadLocalMap.

The relationship between ② ThreadLocal and Thread:

From this picture we can directly see the attribute threadLocals in Thread. As a special Map, its key value is our ThreadLocal instance, and the value value is the value we set.

The operation process of ③ ThreadLocal:

Let's take the get method as an example:

Where getMap (t) returns the threadlocals of the current thread, as shown in the following figure, and then gets the value in the ThreadLocalMap based on the current ThreadLocal instance object as key. If it comes in for the first time, call setInitialValue ().

The process of set is similar:

Note: you can directly t.threadLocals in ThreadLocal because Thread and ThreadLocal are in the same package, and the same Thread can directly access ThreadLocal.ThreadLocalMap threadLocals = null; to declare properties.

What are the pits and points for attention in the use of 4.ThreadLocal

I often see appalling headlines on the Internet. ThreadLocal causes memory leaks, which usually deters developers who don't understand ThreadLocal thoroughly at the beginning. The less you use it, the stranger you are. This makes us miss a better implementation plan, so dare to introduce new technology, dare to step on the pit, can make continuous progress.

Let's take a look at why ThreadLocal causes memory leaks and in what scenarios do they cause memory leaks?

Let's first review what is a memory leak and what is a memory overflow.

① Memory overflow: memory overflow, there is not enough memory for applicants to use.

② Memory leak: memory leak. After the program requests memory, it cannot release the requested memory space. The accumulation of memory leaks will eventually lead to memory overflow.

It is obvious that the irregular use of TreadLocal caused the memory not to be freed.

In the red box, we see a special class WeakReference, which is also rarely used by application developers. Here is a brief introduction.

Type collection time strong references in application scenarios survive all the time, unless GC Roots cannot reach all program scenarios, basic objects, custom objects and other soft references that run out of memory and are generally used for resources that are very sensitive to memory, and many scenarios are used as caches. For example, web page cache and picture cache weak references can only survive to objects with a short life cycle before the next GC, such as Key in ThreadLocal. Virtual references can be recycled at any time, creating garbage collection activities that may be quickly recycled and used within the JVM team to track JVM

Since WeakReference is about to be recycled in the next gc, why isn't there something wrong with our program?

①, so let's test the recovery mechanism for weak references:

This kind of existence strong reference will not be recycled.

No strong references here will be recycled.

The collection of weak references is demonstrated above. Let's take a look at the collection of weak references of ThreadLocal.

Weak reference recovery of ② ThreadLocal

As shown in the figure above, we do not have external strong references to the ThreadLocal object as key. Next time, gc will generate data with a key value of null. If the thread does not end in time, it is bound to appear, a strong reference chain.

Threadref- > Thread- > ThreadLocalMap- > Entry, so this will result in a memory leak.

Let's simulate the memory leak caused by ThreadLocal:

1. For better results, we set the stored value value of our treadlocals to a list of 10, 000 strings:

Class ThreadLocalMemory {/ / Thread local variable containing each thread's ID public ThreadLocal threadId = new ThreadLocal () {@ Override protected List initialValue () {List list = new ArrayList (); for (int I = 0; I < 10000; iTunes +) {list.add (String.valueOf (I));} return list;}} / / Returns the current thread's unique ID, assigning it if necessary public List get () {return threadId.get ();} / remove currentid public void remove () {threadId.remove ();}}

The test code is as follows:

Public static void main (String [] args) throws InterruptedException {/ / to reproduce the scenario in which the key is recycled, we use the temporary variable ThreadLocalMemory memeory = new ThreadLocalMemory (); / / call incrementSameThreadId (memeory); System.out.println ("before GC: key:" + memeory.threadId); System.out.println ("before GC: value-size:" + refelectThreadLocals (Thread.currentThread () / / set to null. Calling gc does not necessarily trigger garbage collection, but you can manually trigger gc collection through some tools provided by java. Memeory.threadId = null; System.gc (); System.out.println ("after GC: key:" + memeory.threadId); System.out.println ("after GC: value-size:" + refelectThreadLocals (Thread.currentThread (); / / Simulation thread has been running while (true) {}}

How do we know there is memory leak in memory at this point?

We can dump the current heap memory with some commands provided by jdk, as follows:

Jmap-dump:live,format=b,file=heap.bin

Then we use the MAT visual analysis tool to view the memory and analyze the survival status of the object instance:

First open our tooltip for our memory leak analysis:

What we can confirm here is that the Entry.value of the ThreadLocalMap instance is not recycled.

Finally, we need to make sure that Entry.key is still there? Open Dominator Tree, search our ThreadLocalMemory, and find that there are no living instances.

Above we reproduce the memory leak caused by improper use of ThreadLocal. Demo is here.

So we summarized the prerequisites for memory leaks when using ThreadLocal:

The ① ThreadLocal reference is set to null, and there is no set,get,remove operation following it.

The ② thread runs all the time and does not stop. (thread pool)

③ triggers garbage collection. (Minor GC or Full GC)

We see that the conditions for memory leaks in ThreadLocal are very harsh, so we only need to break one of these conditions to avoid memory leaks, but in order to better avoid this situation, we follow the following two small principles when using ThreadLocal:

① ThreadLocal is declared private static final.

Private and final try not to allow others to modify and change references.

Static is represented as a class attribute and is recycled only at the end of the program.

Be sure to call the remove method after using ② ThreadLocal.

The simplest and most effective way is to remove it after use.

The above is what the ThreadLocal principle analysis and application scenario is like. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.