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

Why ThreadLocal memory leak, many novices are not very clear, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

What problem does ThreadLocal solve?

In order to solve the problem that the object cannot be shared by multiple threads, the object instance is saved in the threadLocalMap owned by each thread through the threadLocal.set () method, so that each thread uses its own object instance and does not affect each other, thus achieving the effect of isolation, thus solving the thread safety problem caused by the shared access of the object.

What do you mean? For example, now everyone in the company has to fill out a form, but there is only one pen. At this time, only after the individual has finished using it, the next person can use it. In order to ensure the availability of the "pen" resource, you only need to ensure the order in which everyone gets it. This is the function of lock. When this pen is used by someone else, I add lock. When you come, go into the queue and wait for resources (in an unfair way). After using this pen, release lock, and then give it to the next individual in order.

But it is perfectly possible for each person to have a pen. In that case, you fill out your form and I will fill out my form. Neither of us will delay the other. This is what ThreadLocal is doing. Because every Thread has a copy, there is no competition for resources, so there is no need to lock. This is to trade space for time.

Before we begin, let's straighten out the relationship between Thread, ThreadLocal, and ThreadLocalMap:

As you can see, there is a ThreadLocalMap in Thread, ThreadLocalMap is composed of Entry, and there are ThreadLocal and valueThreadLocal in Entry. Why is there a memory leak without moving?

Let's give an explanation here, and then we'll analyze it in detail:

First of all, because ThreadLocal is implemented based on ThreadLocalMap, where Entry of ThreadLocalMap inherits WeakReference, while key in Entry object uses WeakReference encapsulation, that is to say, key in Entry is a weak reference type, which can only survive until the next GC for weak references.

If a thread calls the set setting variable of ThreadLocalMap at this time, a new record will be added to the current ThreadLocalMap, but due to a garbage collection, this will result in a result: the key value is recycled, but the value value is still in memory, and if the thread exists all the time, its value value will always exist

In this way, the garbage collected key will always have a reference chain: Thread-> ThreadLocalMap-> Entry-> Value:

It is because of the existence of this reference chain that if Thread is still running, then Entry will not be recycled, and value will not be recycled, but the key value in Entry has been recycled.

This is just a thread, if there is another thread, there is another thread. Too much will cause a memory leak.

After knowing how the memory leak is caused, it is easy to say what to do next. It is not because the value value has not been recycled that the memory leak is caused.

After using the key value, remove the value value through the remove method, so that there will be no value value in memory, which prevents memory leaks.

Is ThreadLocal based on ThreadLocalMap?

OK, the above content is finished. Let's take a look at it one by one.

First of all, how do you know that ThreadLocal is implemented based on ThreadLocalMap?

I know from the source code.

You can see the following lines of code in the source code:

Public class ThreadLocal {

Static class ThreadLocalMap {

Static class Entry extends WeakReference, where k of Entry is ThreadLocal and v is Object. When super (k) is called, the ThreadLocal instance is wrapped as a WeakReference.

Strong and weak quote this piece of content, Fan, just put a table:

Reference type feature strong reference (Strong Reference) objects associated with strong references will never be recycled by the garbage collector soft reference (Soft Reference) soft reference associated objects, only when the system is about to have a memory overflow, soft reference object weak references (Weak Reference) objects associated with weak references will be recycled, as long as garbage collection events occur The only function of an object associated with a Phantom Reference is to receive a system notification when the object is reclaimed by the recycler

You should be able to see from the table that weakly referenced objects will be reclaimed whenever a garbage collection event occurs.

So the survival time of weak references is just before the next GC.

Here, A Fan has a question to ask: why does ThreadLocal use weak references instead of strong references?

There are some comments on ThreadLocalMap, and I'll take an excerpt here, and maybe get a glimpse of it:

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

The translation is:

To solve the very large and long-term problem, the hash table uses a weakly referenced key

Suppose, what if ThreadLocal uses strong references?

If it is a strong reference, you can also see in the table that the object associated with the strong reference will never be recycled by the garbage collector.

If the referenced ThreadLocal object is recycled, but the ThreadLocalMap still holds a strong reference to the ThreadLocal, if there is no remove, the ThreadLocal is still reachable during the GC, so the ThreadLocal will not be recycled, but what we expect is that the referenced ThreadLocal object will be recycled, which will not achieve the purpose.

If weak references are used, memory leaks may occur, but in the ThreadLocal life cycle, there are operations to recycle when the value of key is null.

So, with weak references, memory leaks can be avoided as much as possible during the ThreadLocal lifecycle.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, 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.