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

This article will explain in detail how to understand the ThreadLocal memory leak. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Preface

The function of ThreadLocal is to provide local variables within a thread, which play a role in the life cycle of a thread, reducing the complexity of passing common variables between multiple functions or components in the same thread. But if ThreadLocal is misused, it can lead to memory leaks.

Principle of ThreadLocal implementation

The implementation of ThreadLocal is like this: 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.

In other words, 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 the Key, and the weakly referenced object is recycled during GC.

Why does ThreadLocal have a memory leak?

ThreadLocalMap uses the weak reference of ThreadLocal as the key, and if a ThreadLocal does not have an external strong reference to reference it, then the ThreadLocal is bound to be recycled when the system GC.

In this way, Entry with key of null will appear in ThreadLocalMap, and there is no way to access the value of Entry with key of null. If the current thread doesn't finish any longer, the value of Entry with key of null will always have a strong reference chain: Thread Ref-> Thread-> ThreaLocalMap-> Entry-> value can never be recycled, resulting in memory leak.

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.

But these passive precautions do not guarantee memory leaks:

The use of static's ThreadLocal extends the life cycle of ThreadLocal, which may lead to memory leaks.

If the allocation uses ThreadLocal and no longer calls the get (), set (), remove () methods, it will result in a memory leak.

Why use weak references

On the surface, the root cause of the memory leak lies in the use of weak references. Most online articles focus on memory leaks when ThreadLocal uses weak references, but another question is also worth thinking about: why use weak references instead of strong references?

Let's first look at what the official documents say:

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.

For very large and long-term uses, hash tables use weakly referenced key.

Let's discuss it in two situations:

Key uses strong references: objects referenced by ThreadLocal are recycled, but ThreadLocalMap also holds strong references to ThreadLocal. If it is not manually deleted, ThreadLocal will not be recycled, resulting in Entry memory leaks.

Key uses weak references: objects of referenced ThreadLocal are recycled, and because ThreadLocalMap holds a weak reference to ThreadLocal, ThreadLocal is recycled even if it is not manually deleted. Value will be cleared the next time ThreadLocalMap calls set,get,remove.

Comparing the two situations, we can find that:

Since the life cycle of ThreadLocalMap is as long as that of Thread, memory leaks will occur if the corresponding key is not manually deleted. However, using weak references can provide an additional layer of protection: weak references to ThreadLocal will not cause memory leaks, and the corresponding value will be cleared the next time ThreadLocalMap calls set,get,remove.

Therefore, the root cause of the ThreadLocal memory leak is that because the life cycle of ThreadLocalMap is as long as Thread, it will cause a memory leak if the corresponding key is not manually deleted, not because of weak references.

ThreadLocal practice

Based on the above analysis, we can understand the causes and consequences of ThreadLocal memory leaks, so how to avoid memory leaks?

Every time you finish using ThreadLocal, you call its remove () method to clear the data.

In the case of thread pools, not cleaning up the ThreadLocal in a timely manner is not only a memory leak problem, but also may lead to business logic problems. So, using ThreadLocal is the same as unlocking after locking, cleaning up after using it.

On how to understand the ThreadLocal memory leak problem to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.