ThreadLocal is a relatively common tool class used in development to ensure thread-safety in multi-threaded environments. The basic principle is that each object is assigned a private object belonging to the current thread, so that the objects held by the threads do not conflict with each other.
It can be imagined that when more than one person share a toilet, many people cannot use the toilet carelessly because of some restrictions of the toilet. If each person is given a separate toilet when they come, they will not disturb each other. The disadvantages are also obvious that it is a waste of resources. So remember to destroy resources when you run out of them.
When will you use ThreadLocal again, some might ask?
- In Spring transactions, the default internal use of ThreadLocal is to assign a separate connection to each thread, but this is encapsulated internally, not written by us
- In Web applications, sometimes you have to do some separate processing for some requests and some extra processing for the response, and everybody writes it differently, and I’ve seen some people have a thread for each request, and they have some ThreadLocal variables for each request that store the information about the request, So that you can retrieve it from ThreadLocal later in the process
- The most common example is SimpleDateFormat, which can cause problems with multiple threads. In high concurrency scenarios, ThreadLocal is used to assign one SimpleDateFormat object to each thread.
Think about it when you know how it works, or if you can use ThreadLocal in your own scenario.
The internal structure
It is still not enough to know the basic usage of it, and its internal data structure is also very interesting. It was only after looking at it that I found the cleverness.
- Within each Thread objects are a ThreadLocal ThreadLocalMap attribute, the attribute name threadLocals, after creating threads can be directly through t.t hreadLocals access
When calling ThreadLocal’s set method:
- Gets the ThreadLocalMap attribute of the current Thread. If the ThreadLocalMap of the current Thread is empty, it is initialized and assigned; if it is not empty, it is directly assigned
When there are multiple ThreadLocal objects, the Entry array in each thread’s internal ThreadLocalMap property is mod to the hashCode of ThreadLocal, and then the Entry object is constructed.
A thread can store multiple thread-private objects within a thread, but ThreadLocal objects are the entry points to those thread-private objects.
Memory leak problem
Will memory leak if ThreadLocal is not removed?
The Entry table in the ThreadLocalMap attribute of a Thread is a weakly referenced object whose reference is a ThreadLocal object. Therefore, the weakly referenced object will be collected during garbage collection.
ThreadLocal without strong external references is reclaimed during GC, and if the thread that created the ThreadLocal keeps running, then the value in the Entry object may not be reclaimed, resulting in memory leaks.
Remember to call the threadlocal. remove method after using ThreadLocal.
The last
ThreadLocal = ThreadLocal = ThreadLocal = ThreadLocal
- Reference types
- Map data structure
- Thread safety
- Usage in real world scenarios
I hope it helps
reference
- Java interview must ask -ThreadLocal