Understanding Java Classloader Memory Leaks and PermGen Space Errors in Servlets

When you redeploy an application and encounter a java.lang.OutOfMemoryError: PermGen space, it may not be a simple server bug; the error can stem from your own code causing classloader memory leaks.

The article introduces a servlet example that, after multiple redeployments, eventually fails with the PermGen error, prompting an investigation into the underlying cause.

In application servers such as GlassFish, each deployed application runs with its own classloader. When an application is not in use, its classloader and the classes it loaded should become eligible for garbage collection. However, lingering references to the classloader prevent this, leading to PermGen exhaustion.

PermGen (Permanent Generation) is a fixed-size region of the JVM heap used to store class metadata. Its size can be set with -XX:MaxPermSize (default 64 MB on Sun VMs). Even if the regular heap has free space, the JVM cannot allocate more class metadata once PermGen is full, and the -Xmx option does not affect it.

The article then walks through the servlet example, showing memory diagrams that illustrate how objects loaded by the application classloader (shown in yellow) remain reachable through static fields and inner classes, preventing the classloader from being reclaimed.

Key points highlighted include:

Each servlet instance holds a reference to its class object (e.g., Servlet1.class).

Each class object holds a reference to the classloader that loaded it.

The classloader holds references to all classes it loaded.

If any object outside the application classloader points to a class loaded by it, the entire classloader hierarchy becomes non‑collectable, causing a classloader leak.

The conclusion emphasizes that external references to classes loaded by an application's classloader are the root cause of classloader memory leaks.

Additional potential issues are discussed, such as static caches in libraries (e.g., Apache Commons BeanUtils) that retain Method objects, which in turn keep class references alive when the library is loaded by the server classpath.

A simple remedy is to ensure that any threads started by the application are stopped when the application is undeployed.

Detecting and fixing classloader leaks is difficult because it requires repeated load/unload cycles and often relies on analyzing heap dumps. New tools introduced in JDK 6 can help, but the process remains complex.

For more details, the original article is available on the company wiki.