WebSphere Memory leak Detection and Protection

Tomcat provides excellent memory leak protection and detection features. Starting with tomcat 6.0.25, the manager webapp has a new "Find Leaks" button. When triggered, it displays a list of webapps (their context path) that have been stopped (this includes undeployed and redeployed ones) but whose classloader failed to be GCed.There are two parts to the new memory leak features*-

1. The first part handles memory leak prevention and is implemented as a life-cycle listener, the JreMemoryLeakPreventionListener. This listener prevents memory leaks by calling various parts of the Java API that are known to retain a reference to the current context class loader. If a web application is the first code to call one of these standard Java APIs, the web application class loader will be pinned in memory which will cause a memory leak. By making sure that Tomcat code makes the calls first, the memory leaks are prevented. If you want to know the gritty details of what this listener actually does, the src  is pretty well commented.
2. The second part of the new features handles detection. This code executes when a web application is stopped, un-deployed or reloaded. It checks, via a combination of standard API calls and some reflection tricks, for known causes of memory leaks and - where it can - fixes them. These checks are implemented in the WebappClassLoader. As always with Tomcat, if you want the details you can look at the WebappClassLoader.java. Start with the clearReferences() method.

All JEE application servers will benefit greatly from these features. If your JEE application and application server suffers from these memory leaks consider implementing this leak prevention and detection function following the steps below -

1. For leak prevention modify the JreMemoryLeakPreventionListener to implement javax.servlet.ServletContextListener and leverage the servlet spec. mandated ServletContainer lifecycle events instead of the proprietary org.apache.catalina.LifecycleEvent events passed to the LifecycleListener interface. 
2. Leak detection is more complicated.  You can take two approaches to skinning this cat.

• You will need first encapsulate and later port the code in org.apache.catalina.loader.WebappClassLoader.clearReferences() to a simple delegation classloader that plugs in after the webappclassloader i.e. all classes will first be loaded from the custom classloader that will delegate up to the webappclassloader. This way you do bookkeeping on the classes loaded in the custom classloader. Later when the application stops call the clearReferences method that operates on the loaded classes. 
• Alternately you will need to figure out a way to access/list ALL the classes (Class objects) loaded by your web application's classloader. With this list in hand you will call clearReferences* methods on those classes once the application stops. //org.apache.catalina.loader.WebappClassLoader.clearReferences( protected void clearReferences() { clearReferencesJdbc(); clearReferencesThreads(); clearReferencesThreadLocals(); clearReferencesRmiTargets(); if(ENABLE_CLEAR_REFERENCES) clearReferencesStaticFinal(); IntrospectionUtils.clear(); if(clearReferencesLogFactoryRelease) LogFactory.release(this); clearReferencesResourceBundles(); Introspector.flushCaches(); } //Custom Leak Detection Classloader to extend the abstract Classloader //Classloader API public abstract class ClassLoader { public Class loadClass(String name); protected Class defineClass(byte[] b); public URL getResource(String name); public Enumeration getResources(String name); public ClassLoader getParent() }

Please let me know if these approaches worked for you.

* From  http://www.tomcatexpert.com/blog/2010/04/06/tomcats-new-memory-leak-prevention-and-detection