Memory leak when redeploying application in Tomcat

Question

When I redeploy my application in tomcat, I get the following issue:

 The web application [] created a ThreadLocal with key of type  [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@10d16b])  and a value of type [com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty] (value [com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty@1a183d2]) but   failed to remove it when the web application was stopped.   This is very likely to create a memory leak. 

Also, am using ehcache in my application. This also seems to result in the following exception.

     SEVERE: The web application [] created a ThreadLocal with key of type [null]       (value [com.sun.xml.bind.v2.ClassFactory$1@24cdc7]) and a value of type [java      .util.WeakHashMap...  

The ehcache seems to create a weak hash map and I get the message that this is very likely to create a memory leak.

I searched over the net and found this, http://jira.pentaho.com/browse/PRD-3616 but I dont have access to the server as such.

Please let me know if these warnings have any functional impact or can they be ignored? I used the "Find Memory leaks" option in tomcat manager and it says "No memory leaks found"

Answer 1

When you redeploy your application, Tomcat creates a new class loader. The old class loader must be garbage collected, otherwise you get a permgen memory leak.

Tomcat cannot check if the garbage collection will work or not, but it knows about several common points of failures. If the webapp class loader sets a ThreadLocal with an instance whose class was loaded by the webapp class loader itself, the servlet thread holds a reference to that instance. This means that the class loader will not be garbage collected.

Tomcat does a number of such detections, see here for more information. Cleaning thread locals is difficult, you would have to call remove() on the ThreadLocal in each of the threads that is was accessed from. In practice this is only important during development when you redeploy your web app multiple times. In production, you probably do not redeploy, so this can be ignored.

To really find out which instances define the thread locals, you have to use a profiler. For example the heap walker in JProfiler (disclaimer: my company develops JProfiler) will help you to find those thread locals. Select the reported value class (com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty or com.sun.xml.bind.v2.ClassFactory) and show the cumulated incoming references. One of those will be a java.lang.ThreadLocal$ThreadLocalMap$Entry. Select the referenced objects for that incoming reference type and switch to the allocations view. You will see where the instance has been allocated. With that information you can decide whether you can do something about it or not.