Click on the “blue word” above to follow us
The fourth original article
Writing in the front
In this article, we will focus on the problem of memory leakage in ThreadLocal.
Can ThreadLocal leak memory?
Conclusion: Memory leaks are possible if you don’t use them properly.
ThreadLocal and current Thread stack layout diagram
Each Thread contains a ThreadLocalMap, and the real data in a ThreadLocalMap is an array of entries whose keys are weak references to threadLocal objects.
The Entry Key is a weak reference to the ThreadLocal object. Why use a weak reference?
First, what is a weak reference?
Weak references are generally used to describe non-essential objects, and objects associated with weak references can only survive until the next garbage collection occurs. When the garbage collector works, objects associated only with weak references are reclaimed regardless of whether there is currently enough memory.
In practice, when a threadLocal is no longer needed and the threadLocal variable is set to null for GC, the threadLocal object in the heap will be reclaimed by GC. Suppose the Key now holds a strong reference to a ThreadLocal object. If the current thread is still running, then there is a strong reference from the current thread all the way to the threadLocal object, and the threadLocal object cannot be GC because the current thread is still running. This is a memory leak. Weak references, on the other hand, do not have this problem. When the threadLocal variable in the stack is set to null, the threadLocal object in the heap has a weak reference association of only one Key, and the threadLocal object in the heap will be reclaimed during the next GC. Using weak references does not leak memory for ThreadLocal objects.
So, the second question is, does a weak reference to a ThreadLocal object that the Key holds necessarily prevent memory leaks?
The bottom line: it’s still possible to leak memory if you don’t use it right, but it’s a different place.
When threadLocal is used up, set the threadLocal variable in the stack to NULL, and the threadLocal object will be collected in the next GC, and the weak reference key associated with the Entry will become NULL. If the current thread is still running at this point, A Value object with a null key in the Entry will not be recycled (there is a strong reference), which will result in a memory leak. If the current thread completes its execution and is recycled, then the Value will also be recycled, but if the thread pool is used, A memory leak occurs when the thread is put back into the thread pool (the thread is not destroyed and is not reclaimed) and the Value persists.
How best to reduce the risk of memory leaks?
In order to reduce the possibility of memory leakage, ThreadLocal removes all null values in the Entry array of ThreadLocalMap during set, GET, and remove. Therefore, we can reduce the risk of memory leaks by calling threadLocal’s remove method after the current thread has used threadLocal.
If you want to follow my updated articles and the dry goods I share in real time, you can follow my official account we are all guinea pigs.
Thank you for your attention, if you like, you can click on the bottom right to see, and you are welcome to share this article with more friends, thank you!
Make a little progress every day! ! !
On the evening of 2020.05.20
