How to understand Entry inheritance WeakReference of ThreadLocal

This article mainly introduces "how to understand ThreadLocal's Entry inheritance WeakReference". In daily operation, I believe many people have doubts about how to understand ThreadLocal's Entry inheritance WeakReference. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "how to understand ThreadLocal's Entry inheritance WeakReference". Next, please follow the editor to study!

Introduction: why does ThreadLocal's Entry inherit WeakReference? Will it be recycled when a weak reference to GC is made? So if it is recycled, will the data not be lost?

First, take a look at the code of WeakReference, which inherits from Reference. Here is a get () method, which looks like this:

Note this sentence:

If this reference object has been cleared, either by the program or by the garbage collector, then this method returns null.

That is, the referent field will be modified during GC, and it will become null after GC.

If you look at the Entry mentioned in the question, the code is here:

Note this sentence:

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.

At this time, we should pay attention to one thing. I just mentioned that after ThreadLocal is GC, the reference in Entry will become null. However, after all, Entry is also an object. It is not unusual except that it will be changed by reference during GC. When will the value here be destroyed?

Anyway, it will not be deleted along with ThreadLocal, or even whether it can be destroyed is a question. It is impossible for the GC thread to change the value when changing the reference, so the value can only be deleted by ourselves.

So take a look at ThreadLocal's only three instance member methods of public, that is, get, set, and remove, which actually end up calling ThreadLocalMap's getEntry, set, and remove methods.

GetEntry may be transferred to expungeStaleEntry;set through getEntryAfterMiss, or to replaceStaleEntry through cleanSomeSlots, or to expungeStaleEntry through rehash, then to expungeStaleEntry through rehash, or to cleanSomeSlots and expungeStaleEntry; through replaceStaleEntry, while remove may also be adjusted to expungeStaleEntry.

In short, all roads lead to Rome, and nine times out of ten, they will end up in expungeStaleEntry, but in fact, the author has already warned us when he wrote a note:

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.

The realization of expungeStaleEntry

This is where Entry's value is set to null, and this is where Entry in ThreadLocalMap's table is set to null.

So what is the function of weak reference? as long as you search the source code of ThreadLocal for = = null, you will find that every place where it appears is to judge reference. In this code, you can judge whether Entry is still useful or not by judging reference. What needs to be GC most is value in Entry, while ThreadLocal itself is very small. There is only one threadLocalHashCode in it.

At this point, the study on "how to understand ThreadLocal's Entry inheritance WeakReference" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!