Path to Leaking Application Class Loaders

List all leaked application classloaders with path to GC roots.

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.

Screenshot of list of leaking loaders

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.

Screenshot of paths to gc roots for leaking loader

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.