https://bz.apache.org/bugzilla/show_bug.cgi?id=59138
--- Comment #3 from Brett Kail <bjk...@gmail.com> --- Entries in ThreadLocalMap weakly reference the key, which is the ThreadLocal subclass that is loaded by the application class loader. Assuming there are no other retained references to the application class loader, the JVM will clear this weak reference at the next GC. This is basically the same as a WeakHashMap, and the javadoc there describes the same semantics: in order for the entry to be cleared, you need to ensure the value does not refer to the key. Assuming the ThreadLocal subclass is held in a static variable (common case), that means the value must not reference anything that directly/indirectly references the application class loader. In this case, the value refers to the bootstrap class loader only, so the ThreadLocal entry does not pin the application class loader. I cannot reproduce a memory leak, but I can reproduce the false positive: 1. Start an empty Tomcat instance (no webapps) 2. Use jvisualvm, collect a heapdump, run the "select x from org.apache.catalina.loader.WebappClassLoader x" OQL, and see "The query returned no results" (baseline) 3. Deploy a WAR that contains a servlet with a static ThreadLocal subclass, and have the doGet method set the ThreadLocal to an integer. 5. Use jvisualvm again, and see there is one class loader 6. Ping the servlet so that the ThreadLocal is loaded 7. Undeploy the WAR, and see the checkThreadLocalMapForLeaks message 8. Use jvisualvm again, and see there are no class loaders In this case, the message is a false positive. The presence of the ThreadLocal does not prevent the class loader from being garbage collected. However, if I change step #3 to set the ThreadLocal to the servlet instance itself, then I see the class loaders accumulate as I repeat this process. Are you able to reproduce these steps? Can you provide more details on what you did to create the memory leak? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
