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

This article mainly introduces "what is the role of ThreadLocal in Java". In daily operation, I believe that many people have doubts about the role of ThreadLocal in Java. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts about "what is the role of ThreadLocal in Java?" Next, please follow the editor to study!

Prologue

Zhang San was in a hot weather recently and was not in a good mood, so he decided to go out for an interview and chat with the interviewer. As a result, someone had an appointment for an interview as soon as he submitted his resume.

I lost, how come someone asked me for an interview as soon as it was delivered? Ah. Really annoying ah, I have not been in jianghu for so long, jianghu still has elder brother's legend, am I still so popular? It's too annoying, handsome and innocent.

Secretly overjoyed, Zhang San came to the office of some east on-the-spot interview, I lost, this interviewer? Come on, this is full of scratched Mac, this volume, is it the legendary architect?

Zhang San's state of mind suddenly broke down, and he met a top interviewer in his first interview. Who can stand this?

Hello, I am your interviewer Tony, look at my hairstyle you should be able to guess my identity, I do not say, let's just start? See that your resume is multithreaded. Please talk to me about ThreadLocal. I haven't written the code for a long time. I'm not familiar with it. Please help me remember it.

I lost it? Is this TM a human voice? What kind of logic is this, it is said to ask multithreading and then come up with such an unpopular ThreadLocal? The state of mind is broken. Besides, you TM yourself forgot to read a book. Come to me to find out what the answer is.

Despite his reluctance, Zhang San ran his little head at high speed, recalling the details of ThreadLocal.

To be honest, the interviewer didn't use ThreadLocal very much in the actual development process. When I was writing this article, I deliberately opened dozens of projects on my computer and searched ThreadLocal globally. I found that in addition to the use of system source code, it is rarely used in projects, but there are still some.

The main function of ThreadLocal is to do data isolation, the filled data only belongs to the current thread, the data of variables is relatively isolated to other threads, in the multi-thread environment, how to prevent their own variables from being tampered with by other threads.

Can you tell me what is the use of isolation and what scenarios it will be used in? This, I said I seldom use, but also asked me, uncomfortable ah, oh, I remember, transaction isolation level.

Hello, interviewer. In fact, the first thing I thought of was the source code for Spring to achieve transaction isolation level, which I accidentally found when I was dumped by my girlfriend when I was crying in the library.

Spring uses Threadlocal to ensure that database operations in a single thread use the same database connection. At the same time, in this way, the business layer does not need to perceive and manage connection objects when using transactions, and skillfully manage the switching, suspension and recovery of multiple transaction configurations through the propagation level.

ThreadLocal is used in the Spring framework to achieve this isolation, mainly in the TransactionSynchronizationManager class. The code is as follows:

Private static final Log logger = LogFactory.getLog (TransactionSynchronizationManager.class); private static final ThreadLocal resources = new NamedThreadLocal ("Transactional resources"); private static final ThreadLocal synchronizations = new NamedThreadLocal ("Transaction synchronizations"); private static final ThreadLocal currentTransactionName = new NamedThreadLocal ("Current transaction name"); …

Spring transactions are mainly achieved by ThreadLocal and AOP, I would like to mention here, we know that each thread's own link is saved by ThreadLocal, I will elaborate on the details in the Spring chapter, warm?

In addition to the scenarios where ThreadLocal is used in the source code, do you use his own scenarios? How do you usually use it?

Here it comes, here comes the plus item. I've really met this before, and the opportunity to install B has finally come.

Some interviewers, I can do this!

Earlier, after we went online, we found that the dates of some users were not correct, and it turned out to be the pot of SimpleDataFormat. At that time, we used the parse () method of SimpleDataFormat, and there was a Calendar object inside. Calling the parse () method of SimpleDataFormat will first call Calendar.clear (), and then call Calendar.add (). If one thread calls add () first and then another thread calls clear (), the time for parse () method parsing is not right.

In fact, to solve this problem is very simple, let each thread new its own SimpleDataFormat, but 1000 threads new1000 each SimpleDataFormat?

So at that time, we used thread pool plus ThreadLocal to wrap SimpleDataFormat, and then called initialValue to make each thread have a copy of SimpleDataFormat, thus solving the problem of thread safety and improving performance.

So. Also, I still have, please don't worry to ask the next one, let me add a little more points to delay the interview.

I have a thread in the project that often encounters the object that needs to be passed across several method calls, that is, the Context, which is a state, often the user identity, task information, and so on.

Using a similar chain of responsibility pattern, it is very troublesome to add a context parameter to each method, and sometimes, if the call chain has a third-party library that cannot modify the source code, the object parameters cannot be passed, so I used ThreadLocal to do a modification, so I only need to set the parameters in ThreadLocal before the call, and get it elsewhere.

Before void work (User user) {getInfo (user); checkInfo (user); setSomeThing (user); log (user);} then void work (User user) {try {threadLocalUser.set (user); / / their internal User u = threadLocalUser.get (); wish getInfo (); checkInfo (); setSomeThing (); log ();} finally {threadLocalUser.remove ();}}

I took a look at many scenarios where data isolation such as cookie,session is achieved through ThreadLocal.

By the way, my interviewer allowed me to show a little more breadth of knowledge. In Android, the Looper class takes advantage of the ThreadLocal feature to ensure that there is only one Looper object per thread.

Static final ThreadLocal sThreadLocal = new ThreadLocal (); private static void prepare (boolean quitAllowed) {if (sThreadLocal.get ()! = null) {throw new RuntimeException ("Only one Looper may be created per thread");} sThreadLocal.set (new Looper (quitAllowed));}

Interviewer: I lost it. How does this guy know so many scenes? Also pulled out the Android, come on, sir, now I'm going to test his principle.

Mm-hmm, your answer is very good, so can you tell me the principle of his underlying implementation?

Okay, interviewer, let me first talk about his use:

ThreadLocal localName = new ThreadLocal (); localName.set ("Zhang San"); String name = localName.get (); localName.remove ()

In fact, it is really easy to use. After the thread comes in, it initializes a ThreadLocal object that can be generic. After that, as long as the thread goes to get before remove, it can get the value of the previous set. Note that I am talking about before remove.

It can isolate data between threads, so there is no way for other threads to get the values of other threads using the get () method, but there are ways to do that, as I'll say later.

Let's first take a look at his set source code:

Public void set (T value) {Thread t = Thread.currentThread (); / / get the current thread ThreadLocalMap map = getMap (t); / / get the ThreadLocalMap object if (map! = null) / / verify whether the object is empty map.set (this, value); / / not empty set else createMap (t, value); / / create a map object} for null

You can find that the source code of set is very simple, mainly ThreadLocalMap we need to pay attention to, and ThreadLocalMap is obtained from a variable called threadLocals in the current thread Thread.

ThreadLocalMap getMap (Thread t) {return t.threadLocals;} public class Thread implements Runnable {. / * ThreadLocal values pertaining to this thread. This map is maintained * by the ThreadLocal class. * / ThreadLocal.ThreadLocalMap threadLocals = null; / * * InheritableThreadLocal values pertaining to this thread. This map is * maintained by the InheritableThreadLocal class. * / ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;.

Here we can basically find the truth of ThreadLocal data isolation. Each thread Thread maintains its own threadLocals variable, so when each thread creates a ThreadLocal, the data is actually stored in the threadLocals variable of its own thread Thread, and no one else can get it, thus achieving isolation.

What does the underlying structure of ThreadLocalMap look like?

The interviewer asked a good question, scolding in my heart, can't I have a rest for a while?

Zhang San replied with a smile, since there is a Map, his data structure is actually very similar to HashMap, but if you look at the source code, you can find that it does not implement the Map interface, and his Entry inherits WeakReference (weak reference), and does not see the next in HashMap, so there is no linked list.

Static class ThreadLocalMap {static class Entry extends WeakReference 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 ();}

I see from the source code that ThreadLocalMap will give each ThreadLocal object a threadLocalHashCode when it is stored. During the insertion process, according to the hash value of the ThreadLocal object, navigate to the location in the table, iMagery int I = key.threadLocalHashCode & (len-1).

Then it will judge: if the current position is empty, initialize an Entry object and place it at position I.

If (k = = null) {replaceStaleEntry (key, value, I); return;}

If the location I is not empty, if the key of the Entry object happens to be the key to be set, then refresh the value in the Entry

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

If position I is not empty and key is not equal to entry, find the next empty position until it is empty.

In this way, when get, it will also locate the location in the table according to the hash value of the ThreadLocal object, and then determine whether the key in the Entry object at that location is consistent with the key of get. If it is inconsistent, it will determine the next location. If the conflict between set and get is serious, the efficiency is still very low.

The following is the source code of get, does it feel good to understand:

Private Entry getEntry (ThreadLocal key) {int I = key.threadLocalHashCode & (table.length-1); Entry e = table [I]; if (e! = null & & e.get () = = key) return e; else return getEntryAfterMiss (key, I, e) } private Entry getEntryAfterMiss (ThreadLocal key, int I, Entry e) {Entry [] tab = table; int len = tab.length; / get also gets the I value of table based on ThreadLocal, and then finds whether the key is equal if (e! = null & & e.get () = key). While (e! = null) {ThreadLocal k = e.get (); / / the equals are returned directly, and if the equals are not equal, continue to search to find the equals. If (k = = key) return e; if (k = = null) expungeStaleEntry (I); else I = nextIndex (I, len); e = tab [I];} return null;}

Can you tell me where the object is stored?

In Java, stack memory belongs to a single thread, and each thread has a stack memory, and its stored variables can only be seen in its own thread, that is, stack memory can be understood as thread's private memory, while objects in heap memory are visible to all threads, and objects in heap memory can be accessed by all threads.

So does it mean that the instance of ThreadLocal and its value are stored on the stack?

In fact, it is not, because the ThreadLocal instance is actually held by the class it created (the top should be held by the thread), and the value of ThreadLocal is also held by the thread instance, they are all on the heap, but with some tricks to change the visibility to be visible to the thread.

What if I want to share the thread's ThreadLocal data?

Using InheritableThreadLocal, multiple threads can access the value of ThreadLocal. We create an instance of InheritableThreadLocal in the main thread, and then get the value set by the InheritableThreadLocal instance in the child thread.

Private void test () {final ThreadLocal threadLocal = new InheritableThreadLocal (); threadLocal.set ("handsome"); Thread t = new Thread () {@ Override public void run () {super.run (); Log.i ("Zhang Sanshuai =" + threadLocal.get ());}} T.start ();}

I can output that line of log normally in the child thread, which is also the problem of parent-child thread data transfer mentioned in my previous interview video.

How do you pass it on?

The passing logic is simple. When I mention threadLocals at the beginning of the Thread code, you look down and I deliberately put another variable:

In the Thread source code, let's take a look at what Thread.init does when it is initialized:

Public class Thread implements Runnable {. If (inheritThreadLocals & & parent.inheritableThreadLocals! = null) this.inheritableThreadLocals=ThreadLocal.createInheritedMap (parent.inheritableThreadLocals);. }

I intercepted some of the code, and if the thread's inheritThreadLocals variable is not empty, as in our example above, and the parent thread's inheritThreadLocals also exists, then I give the parent thread's inheritThreadLocals to the current thread's inheritThreadLocals.

Isn't that interesting?

Young man, you do know a lot, so you are a deep ThreadLocal user. Have you found the problem with ThreadLocal?

You mean a memory leak?

I lost, how does this kid know what I want to ask? Uh-huh, that's right, you tell me.

This problem does exist. Let me tell you why. Do you remember the code above?

When ThreadLocal is saved, it will store itself as Key in ThreadLocalMap. Normally, both key and value should be strongly referenced by the outside world, but now key is designed to be WeakReference weak reference.

Let me first introduce you to weak quotes:

Objects with only weak references have a shorter life cycle, and when the garbage collector thread scans the area of memory under its jurisdiction, once an object with only weak references is found, regardless of whether the current memory space is sufficient or not, will reclaim its memory.

However, because the garbage collector is a low-priority thread, objects with only weak references will not necessarily be found quickly.

This leads to a problem that ThreadLocal will be recycled when GC occurs when there is no external strong reference, and if the thread that created the ThreadLocal keeps running, then the value in this Entry object may not be reclaimed all the time, resulting in a memory leak.

For example, the threads in the thread pool are all reused, so after the previous thread instance is processed, the thread is still alive for the purpose of reuse, so the value set by ThreadLocal is held, resulting in memory leakage.

According to reason, when a thread is used up, the ThreadLocalMap should be emptied, but now the thread is reused.

So what's the solution?

Just use remove at the end of the code, just remember to use remove to clear the value at the end of the use.

ThreadLocallocalName = new ThreadLocal (); try {localName.set ("Zhang San") } finally {localName.remove ();}

The source code of remove is very simple, find the corresponding values and leave them empty, so that when the garbage collector collects them, they will be automatically recycled.

So why is ThreadLocalMap's key designed to be a weak reference? if key is not set to weak reference, it will cause the same memory leak scenario as value in entry.

At this point, the study on "what is the role of ThreadLocal in Java" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.