Memory leak in Java web application

Question

I have a web application that uses hibernate 3.6.4 and spring 3.2.4 (mvc, tx and security) and works in tomcat 7. Every time I deploy a new version of my application without restarting tomcat, the memory used by tomcat , increases by approximately 50 MB.

I created several heap heaps and analyzed them using the Eclipse Memory Analyzer. I found out that every time I redistributed the application, a new instance of WebappClassLoader was created. But even after I stopped the application with the tomcat manager, WebappClassLoader remains in memory and does not collect garbage. Therefore, after each redeployment, an additional WebappClassLoader remains in memory and uses about 50 MB of memory.

I used the Eclipse memory analyzer to find the reference paths from WebappClassLoader to the GC roots. As a result, I could not find any strong links that could interfere with WebappClassLoaders.

So what supports the viability of WebappClassLoaders? Where else can I research to find out what the WebappClassLoader from the garbage collection is getting in the way?

I thought it might be the finalize () locking method, which prevents the GC from completing garbage collection. But how can I check this?

Answer 1

Class loaders in theory collect garbage when there is no reference to object instances, and class unloading is not required, but in practice this seems more problematic.

I would recommend reading these two articles.

http://frankkieviet.blogspot.com.au/2006/10/classloader-leaks-dreaded-permgen-space.html

http://frankkieviet.blogspot.com.au/2006/10/how-to-fix-dreaded-permgen-space.html

Answer 2

You can follow the steps presented in “Anatomy of Permanent Memory Leak” . They use Java Visual VM , but the steps and things to check should be the same in Eclipse Memory Analyzer. In this presentation, you can find the possible causes of such leaks.

Also note that if you do not see links to WebappClassLoaders , it is possible that the JVM has a lot of PermGen and PermGen eviction. You can easily verify this by doing a smaller PermGen size and make a couple of redistributions.

Answer 3

just check out this article we used for our project to debug memory leaks in tomcat.

Answer 4

I am not an expert at Tomcat and its reimplementation, but back in the days when we used JBoss, we had a very similar situation. This was due to the fact that the PermGen space does not collect garbage, and every new deployment puts classes there. Therefore, if you are not in Java 8, check if there is an actual “leak” in the permenton space.