See also: https://blog.csdn.net/vicoqi/article/details/79743112
https://blog.csdn.net/X8i0Bev/article/details/101086604
1, in ThreadLocal life cycle, there are these references. Look: solid line represents the strong reference, the dashed lines represent weak.
2, ThreadLocal realize is this: Each Thread ThreadLocalMap maintain a mapping table, the key mapping table is ThreadLocal instance itself, value is a real need to store Object.
3, that is to say ThreadLocal itself is not stored value, it is just as a key to let the thread gets value from ThreadLocalMap. It is noted that the broken line, indicates ThreadLocalMap using ThreadLocal incorporated Key weak, the object is weak references recovered in the GC.
4, ThreadLocalMap use ThreadLocal weak reference as a key, if there is no external ThreadLocal a strong references to refer to it, then the system GC when the ThreadLocal bound to be recovered, so that, ThreadLocalMap key is null will appear in the Entry, there is no way to access the key for the Entry of the value null if the current thread still delay the end, these key for the Entry of the value null will always exist a strong chain of references: thread Ref -> thread -> ThreaLocalMap -> Entry -> value can never be recovered, resulting in a memory leak.
5, is the general, which uses the ThreadLocal presence of a weak reference map, map type is the key to a ThreadLocal.ThreadLocalMap.Map threadlocal example. The Map does use weak references, but only a weak reference for the key. Each key are weak reference point threadlocal. When the threadlocal Examples set is null, no references to any strong threadlocal instance, it will be threadlocal gc recovered.
However, we can not recover the value, and this value will never be accessed, so there is a memory leak. Because there is a strong connection over a reference from the current thread. Only after the end of the current thread, current thread would not exist stack, strong references disconnect, Current Thread, Map value will all be recovered GC. The best practice is to call the remove method threadlocal, which is behind so will say.
6, in fact, ThreadLocalMap been taken into account in the design of this case, plus a number of protective measures: in the ThreadLocal get (), set (), remove () will be cleared when a thread ThreadLocalMap in all key to null value . This point in the previous section also talked about too!
7, but these passive precautions and be sure that no memory leaks:
(1) use of static ThreadLocal, ThreadLocal to extend the life cycle, may lead to memory leaks.
(2) the distribution and use of ThreadLocal no longer calls the get (), set (), remove () method, it will lead to memory leaks, because that memory has always existed.
to sum up:
threadlocal not absolutely thread-safe
1. If not destroyed after the end of the thread, a very large probability of thread-safety issues
2. If, after the end of the thread is destroyed, there should not be thread-safety issues
