ClassLoader memory leak even with minimum configuration
See original GitHub issueFor several weeks I am trying to find out why javamelody
leaks ClassLoader even with following minimum configuration! I created a test web app which is empty really; just has two jars (javamelody-core-1.65.0.jar
and jrobin-1.5.9.jar
) and a minimal web.xml
:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
<display-name>LeakTest</display-name>
<filter>
<filter-name>javamelody</filter-name>
<filter-class>net.bull.javamelody.MonitoringFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>javamelody</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<listener>
<listener-class>net.bull.javamelody.SessionListener</listener-class>
</listener>
</web-app>
I really do not have anything else! no class, no xml, no any other jar file. But when I deploy this web app to apache-tomcat-7.0.47
then I Immediately stop the app (even without trying to view it in browser), tomcat says the app has leaks!! this disappears if I run without javamelody-core-1.65.0.jar
but with jrobin-1.5.9.jar
.
I tried Eclipse Memory Analysis and also YourKit a lot with several configs and settings things to null by reflection but I could not resolve the leak 😠 😢 😫 Please help!
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (3 by maintainers)
Top GitHub Comments
Because javamelody uses java serialization. And your code is not really necessary (otherwise the Tomcat issue 51195 would have been fixed a long time ago).
Using your way, I have seen that there are references to the classloader coming from java.io.ObjectStreamClass$WeakClassKey and $FieldReflectorKey (by using a heap dump in Eclipse MAT, then classloader explorer and path to GC roots). The references are SoftReferences, which by definition are not cleaned by GC but will still be cleaned as needed. So it’s not a real classloader leak, since it will be cleaned as needed.
There is an issue for Tomcat named “Find leaks reports a false positive memory/classloader leak” about that: https://bz.apache.org/bugzilla/show_bug.cgi?id=51195