Threadlocal of memory leaks

The purpose of threadlocal is to provide a value for each thread that uses threadlocal, to bind the value to the thread that uses it, and, of course, each thread can change its bound value independently. If you need to isolate sharing conflicts between multiple threads, you can use threadlocal, which greatly simplifies your program.

For more information about threadlocal, please refer to the ThreadLocal》。 After reading the source code of Threadlocal, I found that if we use it improperly, it could cause a memory leak. By my testing, memory leaks do exist. Although the memory leaks, in theory is not serious. The test code is as follows Threadlocaltest file package Com.teleca.robin; public class threadlocaltest { public  Threadlocaltest () { }threadlocal<content> tl=new threadlocal<content> (); Void start () { SYSTEM.OUT.PRINTLN ("Begin"); Content Content=tl.get (); if (content==null) {content= new content (); Tl.set (content);} System.out.println ("Try to release content data");//tl.set (null);//@1//tl.remove ();//@2tl=null;//@3content=null;// @4system.out.println ("request GC"); System.GC (); try {thread.sleep (1000);}  catch  (interruptedexception e) {//TODO auto-generated catch Blocke.printstacktrace ();} System.out.println ("End");}} Class content{byte data[]=new byte[1024*1024*10];p rotected void finalize () {System.out.println ("I am Released ");}} Running results begintry to release content datarequest Gcend Note We try to release references to TL and content at @3 and @4, so that the Java virtual machine reclaims content. However, the test results indicate that there is a reference to the content so that it cannot be recycled by the Java Virtual machine. We have to hit the @1 or @2 code.To let the Java Virtual Machine Recycle content. Recommended to open @2 instead of @1 to open the code @1 or @2, the result is as follows: Begintry to release content Datarequest GcI Releasedend also note that @3 does not actually affect the running results.   In fact, each thread instance has a THREADLOCALMAP member variable that takes the Threadlocal object as key and threadlocal the bound object as value: We call the Set () method of the Threadlocal , just place the object to be bound in the THREADLOCALMAP member variable of the current thread so that it can be obtained next time through the Get () method. The biggest difference between threadlocalmap and normal map is that its entry is for threadlocal weak references, that is, when Threadlocal has no other reference to be empty, the JVM can recycle threadlocal in GC. To get a null key. For more information on Threadlocalmap, please refer to the Threadlocalmap customized for threadlocal " threadlocalmap maintains the relationship between the Threadlocal object and its bound object, and this threadlocalmap has threshold, when more than threshold, Threadlocalmap will first check the internal threadlocal reference (previously said, Threadlocal is the weak reference can be freed) is NULL, if there is null, then the binding object's reference is set to NULL, To release the Threadlocal bound object, freeing up the location for the new threadlocal. If there is no slate threadlocal, then double threshold. In addition, there are two opportunities to release the memory occupied by the discarded Threadlocal bound object, one, when the hash algorithm gets the table index is exactly a null  key threadlocal, Replace the obsolete with the new threadlocal directly. Second, each time in the Threadlocalmap storage Threadlocal,hash algorithm did not hit both entry, need to create a new entry, You also call Cleansomeslots to traverse a reference to the object that cleans up the deprecated threadlocal bindings in the entry array. In addition, when the thread itself is destroyed, the Threadlocalmap must also be destroyed (Threadlocalmap is a member of the thread object) so that all Threadlocal object value objects bound to that thread, If it is not referenced externally (as is often the case), there is no reference to keep it, so it is destroyed and recycled.   from the above can be seen that Java has taken full account of the tradeoff between time and space, but because the null threadlocal corresponding to the object value in the absence of an external reference, it could not be reclaimed in a timely manner. Threadlocalmap checks are done only when the threshold is reached or when the entry is added, not as if the GC is a timed check, but we can manually pass the Threadlocal remove () method or set (NULL) De-Threadlocalmap the reference to the Threadlocal bound object, and cleans up the memory of the discarded Threadlocal bound object in a timely manner. Remove () tends to do more cleanup work, so it is recommended to use it instead of set (null). It should be stated that, as long as not to the use of threadlocal in a large number of data, the problem is not big, after all, there is a mechanism for recycling. &nBSP; the deprecated threadlocal reference to the object being bound will be cleaned up in the following 4 cases. If there is no reference to the bound object at this time, the binding object can be recycled: 1 thread ends. 2 when the threshold of the thread's threadlocalmap exceeds the maximum value. 3 Storing a Threadlocal,hash algorithm in the threadlocalmap of thread does not hit both entry, but requires a new entry. 4 Manually pass the Remove () method or set (null) of the threadlocal.   So if we rudely set threadlocal to null, instead of calling the Remove () method or set (null), then the object that could cause the threadlocal binding could be recycled for a long time, thus yielding memory leaks.  http://blog.csdn.net/hudashi/article/details/7076880  

Threadlocal memory Leaks (RPM)