An application class loader leak occurs when applications are restarted but their class loaders are not cleaned up. This is often caused by a reference to the application from somewhere else in the server, such as from ThreadLocals. It might also be caused by defects within WebSphere Application Server® itself. If an application class loader leak exists and an application is restarted enough times, this can cause Java or native OutOfMemoryErrors.
The Path to Application Class Loaders query will find all stopped application class loaders and interrogate suspects that cause the class loader to be ineligible for garbage collection. This plug-in works equally well on a PHD heap dump.
In the example below, four leaking application class loaders have been found,
each loading the WC_demo application. These have also been
annotated as a LEAKING LOADER next to the object type and
application name.
Expanding one of the leaking loaders shows all of the "Paths to GC Roots", which are the references to the class loader from other "live" objects. The first entry in the expansion in the shortest series of references that keeps the application class loader alive.
Here the shortest chain of references is from the javax.naming.InitalContext
class which contains a reference to the leaking class loader from a java.util.WeakHashMap
that it maintains.