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

Today, I will talk to you about how to deeply analyze the problem of ThreadLocal memory leak, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to 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.

Next, we will analyze the problem of ThreadLocal memory leaks around three aspects.

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 best practices

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.

After reading the above, do you have any further understanding of how to analyze the ThreadLocal memory leak problem in depth? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.