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

This article is about how to explore the causes of ThreadLocal memory leakage. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

1. First, take a look at the schematic diagram of ThreadLocal:

These references exist throughout the life cycle of ThreadLocal.

Where the solid line represents the strong reference and the dotted line represents the weak reference

2. Implementation of ThreadLocal: each Thread maintains a ThreadLocalMap mapping table. The key of this mapping table is the ThreadLocal instance itself, and value is the Object that really needs to be stored.

3. That is to say, ThreadLocal itself does not store values, it just acts as a key to let threads get value from ThreadLocalMap. It is worth noting that the dotted line in the figure indicates that ThreadLocalMap uses the weak reference of ThreadLocal as key, which will be recycled when GC.

4. ThreadLocalMap uses the weak reference of ThreadLocal as the key. If a ThreadLocal does not have an external strong reference to reference it, the ThreadLocal is bound to be recycled when the system GC. In this way, an Entry with key of null will appear in the ThreadLocalMap, and there will be no way to access these value of Entry whose key is null. If the current thread doesn't finish any longer, These Entry value with key null will always have a strong reference chain: Thread Ref-> Thread-> ThreaLocalMap-> Entry-> value can never be recycled, resulting in memory leaks.

5. Generally speaking, ThreadLocal uses a map with weak references, and the type of map is ThreadLocal.ThreadLocalMap. Key in Map is an instance of threadlocal. This Map does use weak references, but weak references are only for key. Each key has a weak reference to threadlocal. When the threadlocal instance is set to null, there are no strong references to the threadlocal instance, so the threadlocal will be recycled by gc.

However, our value cannot be recycled, and this value will never be accessed, so there is a memory leak. Because there is a strong reference connected from current thread. Only after the current thread ends, the current thread will not be stored in the stack, the strong reference will be broken, and all Current Thread and Map value will be recycled by GC. The best thing to do is to call the remove method of threadlocal, which I'll talk about later.

6. In fact, this situation has been taken into account in the design of ThreadLocalMap, and some protective measures have been added: in ThreadLocal's get (), set (), remove (), all value in thread ThreadLocalMap whose key is null will be cleared. This point was also mentioned in the previous section!

7. But these passive precautions do not guarantee memory leaks:

A. Using static's ThreadLocal to prolong the life cycle of ThreadLocal may lead to memory leaks.

B. Allocation only uses ThreadLocal and no longer calls the get (), set (), remove () methods, which may lead to a memory leak, because this piece of memory will always exist.

Here is the source code:

/ * *

* The entries in this hash map extend WeakReference, using

* its main ref field as the key (which is always a

* ThreadLocal object). Note that null keys (i.e. Entry.get ()

* = = null) mean that the key is no longer referenced, so the

* entry can be expunged from table. Such entries are referred to

* as "stale entries" in the code that follows.

, /

Static class Entry extends WeakReference

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.