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

Reply via email to