Possible reasons for Web Application Memory Leaks-And Solutions

1) Check the version of CGLIB Jar Version deployed in container

And possible known classes in CGLIB which cause memory leak are present in Package - net.sf.cglib.proxy and these are the Classes with bugs
a) LazyLoader b) InvocationHandler c) Enhancer

The fix has been applied in CGLIB 2.2 JAR

2) If your application uses Spring Framework for Dependency Injection and JavaBeans Introspection,make sure the WebApp Domain, deployment descriptor "web.xml" has references to different Spring Listener classes like org.springframework.web.util.Log4jConfigListener & org.springframework.web.context.ContextLoaderListener

Spring offers another listener : org.springframework.web.util.IntrospectorCleanupListener

This is the Listener that flushes the JavaBeans Introspector cache on web app shutdown. Register this listener in "web.xml" to guarantee proper release of the web app class loader and the classes that it holds.

If the JavaBeans Introspector has been used to analyze application classes, the Introspector cache will hold a hard reference to those classes. Consequently, those classes and the web app class loader will not be garbage collected on web app shutdown!

Unfortunately, the only way to clean up the Introspector is to flush the entire cache, as there is no way to specifically determine the application's classes referenced there. This will remove cached introspection results for all other applications in the server too.

Note that this listener is not necessary when using Spring's beans infrastructure, as Spring's own introspection results cache will immediately flush an analyzed class from the JavaBeans Introspector cache.

Application classes hardly ever need to use the JavaBeans Introspector directly, so are normally not the cause of Introspector resource leaks. Rather, many libraries and frameworks do not clean up the Introspector..

Note that a single such Introspector leak will cause the entire web app class loader to not get garbage collected! This has the consequence that you will see all the application's static class resources (like singletons) around after web app shutdown, which is not the fault of those classes!

Possible Solution : Add this code in web.xml and place it before any other Spring Listeners

<listener>
<listener-class>
org.springframework.web.util.IntrospectorCleanupListener
</listener-class>
</listener>

3) Problem with DOM4J JAR

There's a problem with the use of ThreadLocals for caching, it's never cleaned up. If the ClassLoader is thrown away (e.g. if a webapp is reloaded), then the ThreadLocal stuff hold until the Thread dies, which might take a while in a Servlet container where the Threads are pooled. In such situation, DOM4J would prevent the webapp's ClassLoader to be garbage collected, which would creates a a memory leak and eventually an OOM if the webapp is reloaded too many times.

Workaround : if possible,avoid using ThreadLocal class(Programmatically it can be done)

4) Get the latest version of JDOM JAR...the latest version 1.1 has fix for known memory leak issues being caused by org.jdom.input.SAXHandler class in older versions

5) Last but not the least, make sure you have Java Profilers like Eclipse Profiler Plugin(this is the best as far as Iam concerned), JProbe ,VisualGC or JSTAT running against web application server...

Feel free to add any more known bugs which cause memory leaks.....!!

Print this post