This article, the main solution to the doubts: 1. The weak references mentioned in Threadlocal.threadlocalmap, will the weak references be recycled? 2. What is the case for weak reference recycling? 3. Java threadlocal and under what circumstances will the memory leak? With these questions, I simulated the structure of the Threadlocal.threadlocalmap, first show the structure of their own: the realization of a simple threadlocalmap, Inside, a entry is used to store the value of the set method set in the threadlocal called by itself. And the same as the JDK Threadlocalmap inside the entry object's key in WeakReference package. The main method is as follows:
Set run parameters:-VERBOSE:GC look at the output: Here I have simulated a memory leak problem, you can see the full GC after the memory is still occupied, and careful observation can see that the key in this map is already null. In other words, you can't get the value through key, of course map.get (null) is also possible, but Java threadlocal does not do so, because the key==null element in map may not be unique. As you can see from my main method, I have a th=null operation, but there is still a memory leak, the reason for later analysis. But one thing is certain: th=null here can not be as we imagined the threadlocal th reference release, the inside of the Key,value object is also released, there may be doubts I have here to hold the Threadlocalmap reference TM so will not be recycled, but in fact, When you manually set the Java threadlocal to null, the current line Cheng Jinghan holds the Threadlocalmap reference, so it is not recycled I am here and Java is similar. Back to the first 3 questions, one answer: 1. The weak references mentioned in Threadlocal.threadlocalmap, will the weak references be recycled? will be recycled as shown in. Key already has a null condition. The first key is not NULL, the reason is 2nd. All keys have been recycled after the full GC has been experienced. 2. What is the case for weak reference recycling? When a weak reference is scanned into a GC (including MINITORGC and full GC), it is recycled, but there is a precondition that the weak reference is not referenced externally (at this point the external reference is equal to the strong reference). In other words, if I hold a reference to a key in my main method, it will not be recycled even if it is set to a weak reference after it is put in the map. See:
GC log:
3. Java threadlocal and under what circumstances will the memory leak? The answer is no, for example, when we call Threadlocal.set (), we do a work to clean up the key== null element, in the following way: The first step: Threadlocalmap Take the threadlocalhashcode and the length minus one phase, and find out the location of the hash table I. Step Two: entry, if the key is found equal, overwrite the original value! Or find the Key==null, set the value in, and set the traversal of the key==null element and his value to null, freeing the memory. The third step: when the last if condition, do rehash action, namely: the element in the entry to recalculate the hash value, put in the appropriate position, conjecture is to speed up the next visit.
Summary: From this point of view, Java threadlocal to the key using a weak reference, but in order to ensure that no longer memory leaks, in each set.get time to actively key==null entry do the traversal of the recovery. Although it does not cause a memory leak, but because the entry does not make a key==null judgment on each set,get, freeing up memory, it may cause large objects to survive in memory for a long time, thus occupying memory. Therefore, it is better to remove the object manually after we have finished using threadlocal, or at least to invoke the next threadlocal.set (null). It is important to note that the key in ThreadLocal is currently the current ThreadLocal itself, like the above simulation of the external holding a strong reference case, the key==null situation in threadlocal.threadlocalmap rarely occur, because, In most cases, threadlocal is always present in singleton mode.
- Weakreferencetest.rar (7.6 KB)
http://liuinsect.iteye.com/blog/1827012
Threadlocal If a memory leak is caused by the analysis (GO)
