ClassLoader Leak Prevention library version 1.11.0 released

Version 1.11.0 of my ClassLoader Leak Prevention library has been released.

Apart from minor tweaks it contains the following features:

Grab the new version via Maven central or download the jar here.


ClassLoader Leak Prevention library version 1.10.0 released

Version 1.10.0 of my ClassLoader Leak Prevention library has been released.

Apart from minor improvements it contains protection against a leak caused by Caucho Resin version < 4.0.40. It is however recommended that you upgrade to Resin 4.0.40+.

Grab it via Maven central or download the jar here.


ClassLoader leaks at JavaForum Gothenburg

Tonight I have talked about ClassLoader leaks at JavaForum Gothenburg. Below you will find the slides from the presentation, the link to the Leak prevention library on GitHub and links to all the parts of the blog series I made on the subject.



Heinz Kabutz Java Specialists’ Newsletter The Law Of The Blind Spot referenced on slide 26.
Tomcat Bugzilla entries #48895 and #49159 referenced on slide 41.

Leak prevention library

GitHub project

Links to all parts in blog series

Part I – How to find classloader leaks with Eclipse Memory Analyser (MAT)

Part II – Find and work around unwanted references

Part III – “Die Thread, die!”

Part IV – ThreadLocal dangers and why ThreadGlobal may have been a more appropriate name

Part V – Common mistakes and Known offenders

Part VI – “This means war!” (leak prevention library)

Better compareTo() syntax

I’ve never really been a big fan of the syntax of java.lang.Comparable.compareTo(). For some reason I find myself constantly referring to the JavaDocs to remind me whether < 0 or > 0 means the argument is less vs more than the callee.

So I decided to do something about it, and created a minimal API with the sole purpose of improving readability of compareTo().

The API supplies methods in two flavors, expressive or abbreviated. The expressive version looks like this:

import static;

  boolean oneIsZero = is(1).equalTo(0);
  boolean aIsNotZero = is(a).notEqualTo(0);
  boolean bIsZero = is(b).zero();
  boolean value1LessThanValue2 = is(value1).lessThan(value2);
  if(is(a).lessThanOrEqualTo(b)) {

  boolean date1AfterDate2 = is(date1).greaterThan(date2);

  if(is(a).greaterThanOrEqualTo(b)) {


The abbreviated syntax looks like this:

import static;

  boolean oneIsZero = is(1).eq(0);
  boolean aIsNotZero = is(a).ne(0);
  boolean value1LessThanValue2 = is(value1).lt(value2);

  if(is(a).le(b)) {

  boolean date1AfterDate2 = is(date1).gt(date2);

  if(is(a).ge(b)) {


The API is available on Maven Central:


Source are on GitHub.

Manual download here.

Debugging third party libraries with AspectJ and Maven

Once in a while you may find yourself in a situation, where you need to debug a third party library on a production server or other environment where it is not possible or impractical to attach a debugger. It may also be the case that modifying the sources of that library and compiling a custom version is not an option (due to compilation dependencies, licenses, source not available or whatnot).

I found myself in such a situation a while back when I needed to understand memory leaks in OpenOffice JURT. I achieved this by injecting debug logging into the library with AspectJ, and in this post I will describe how.

In my situation the third party library was a transitive Maven dependency. In order to weave this library with my own aspects, I added this to the pom.xml:

          <!-- Weave third party dependency -->
        <!-- Weave on compile -->

Note! In order for the weaved version of the library to be included in your .war, the above should be located in the web module if your Maven project has multiple modules. If your aspect is in another module you also need to add


to the configuration.

You’ll likely also want to add the AspectJ runtime dependency, for the aspect implementation.


Now lets move on with the actual aspect. If you need an introduction to AspectJ, you may find this post useful. First we have our aspect class:

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

 * AspectJ aspect used for debugging memory leaks caused by OpenOffice JURT
 * @author Mattias Jiderhamn
public class JURTDebugAspect {
  private static final Logger LOG = LoggerFactory.getLogger(JURTDebugAspect.class);

  /** Utility method to get StackTraceElement of caller */
  private static StackTraceElement getCaller(int levels) {
    StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
    return stackTrace[levels + 1];


Inside that aspect class, we can add different joinpoints and advice to inject logging.

  public void addCalled() {
    LOG.warn("JURT: add() called by " + getCaller(3));

This will log calls to the third party API add() method, including calls from other third party libraries. Note that “execution” pointcut is used rather than “call” pointcut, since we are weaving the callee, not the caller. The getCaller() utility method also allows us to see what code called the add() method.

  @Before("call(* java.lang.Thread.start(..)) && within(*) && target(thread)")
  public void threadStarted(Thread thread) {
    LOG.warn("JURT: Thread.start() called by " + getCaller(2) + " on thread named " + 
      thread.getName() + " of type " + thread.getClass().getName());

Here we add some logging for when the third party library calls the start() method on java.lang.Thread, and include the name and type of the started thread.

  @Around("call(*$ && within(*) && target(job)")
  public Object jobRun(ProceedingJoinPoint proceedingJoinPoint, Object job) throws Throwable {"JURT: starting: " + job.getClass().getName() + " in thread " +
    final long start = System.currentTimeMillis();
    try {
      return proceedingJoinPoint.proceed();
    finally {"JURT: done: " + job.getClass().getName() + " in thread " +
        Thread.currentThread().getName() + "; took " + 
        (System.currentTimeMillis() - start) + " ms");

Here we log internal calls to inside the API, and measure the time that those calls take. The name of the Job subclass is included.

Good luck debugging third party libraries!

Agile code review at nForum – video

When I talked about agile code review on nForum the other day, I made a screencast recording, which is now online. (I admit sound quality could have been somewhat better.)

For better readability of the slides, I recommend viewing the video in HD on Vimeo

Note that the slides and links to code review tools and further reading are in my previous post.

If you want to share the video, please link to this post rather than directly to Vimeo.

Agile code review at nForum

Tonight I’ve given a talk at nForum Göteborg on code review and how it can be used by agile teams. It was pretty much the same talk I gave at JavaForum a while back. I tried to make a recording of it, and will post a video and update this post, if successful.

Here are the (Swedish) slides:

Here are links to some code review tools:

In addition to this list, code review is one of the features of GitHub. In my opinion it has the same problems as e-mail based review, where it is hard to track what has been fixed and not.

Some reading suggestions on code review:
Coding Horror blog entry
Free book from the authors of Code Collaborator
White paper from the authors of Klocwork

Aspect-Oriented Programming (AOP) with AspectJ – an introduction

Tonight I have delievered a talk at JavaForum Gothenburg about Aspect-Oriented Programming (AOP) in general and AspectJ in particular.

Here are the slides of the presentation:

You will find the source code of the demos, including pom.xml to configure Maven for AspectJ weaving, on my GitHub account:

I intended to record the session as a screencast, but unfortunately my IDE decided freak out when I started coding some examples, so I had to restart it and decided to trash the recording in order to save time. There was a video camera present during the evening however, so maybe a video will turn up on the net at some time. I will however be grateful if the couple of minutes with crashing IDE is edited…

Classloader leaks VI – “This means war!” (Leak Prevention library)

This post is intended to conclude the series about classloader leaks, and I want to use it to declare war! (Not as in Web application archive though…)

I have decided to pursue the fight against classloader leaks, and I invite you to join me. For this purpose I have created a project on GitHub called classloader-leak-prevention. The project consists of two parts.

Classloader leak protection listener

First and foremost there is a component for you to add to your web application, that intends to remove and work around as many of the known issues as possible. This will allow us not to depend on bugs being fixed in third party libraries. Yes, this is somewhat like what Tomcat has built in, but my component covers cases that Tomcat currently does not. Another major advantage is that my component is Application Server independent.

It should be as easy as adding a JAR or .java file, configuring a ServletContextListener in web.xml, and you should be protected against java.lang.OutOfMemoryError: PermGen space caused by your app leaking classloaders (you could still run out of PermGen however, or other apps on the same server may leak). In due time, I hope that parts of it will be configurable to your needs (check back here for updates). If it is not configurable enough, feel free to subclass or create your own GitHub fork.

To configure the main prevention mechanism, just add the component to your project and insert this into your web.xml:


It makes sense to keep this listener “outermost” (initializing first, destroying last), so you should normally declare it before any other listeners in web.xml.


The library is available in Maven Central with the following details:



Non-Maven users can download the JAR with the current version (1.15.2) of the project » here «.


The context listener has a number of settings, see the readme on GitHub.

Classloader leak detection / test framework

Another part of the project, is a framework that allows the creation of JUnit tests, that confirms classloader leaks in third party APIs. It is also possible to test leak prevention mechanisms to confirm that the leak really is avoided.

Read more about this on GitHub.


This project is licensed under the Apache 2 license, which allows you to include modified versions of the code in your distributed software, without having to release your source code.

Links to all parts in the series

Part I – How to find classloader leaks with Eclipse Memory Analyser (MAT)

Part II – Find and work around unwanted references

Part III – “Die Thread, die!”

Part IV – ThreadLocal dangers and why ThreadGlobal may have been a more appropriate name

Part V – Common mistakes and Known offenders

Part VI – “This means war!” (leak prevention library)

Presentation on Classloader leaks (video and slides)

Classloader leaks V – Common mistakes and Known offenders

If you just want a quick fix to the problem without understanding the theory, jump to part IV introducing the ClassLoader Leak Prevention library.

A couple of years ago, there was an article on the Confluence site of the Spring framework written by Magnus Alvestad, titled “Memory leaks where the classloader cannot be garbage
collected” (originally located here/here). Apart from a short description of the problem with classloader leaks, it also contained a list of known offenders; practices and third party libraries known to cause classloader leaks, either by incorrect use or as a bug.

Even though not by far exhaustive, an article like that was a good reference – a place to start looking if you experienced java.lang.OutOfMemoryError: PermGen space. Unfortunately it seems that page is not available any more. My hope for this post is that it may serve that purpose instead. For that to come true, I also need your help. If you know of a public Java library that does, in a current or previous version, cause classloader leaks, please comment on this post. I intend to keep the list updated. (Please note that this is not an invitation for support requests, asking me whether a particular library does leak. I want you to report leaks that are confirmed, either by yourself or that there is an online bug report / mailing list discussion. References are preferrable!)

Common mistakes

Let’s start with the leaks that aren’t necessarily bugs, but failure to follow guidelines or best practice. It may also be API:s that have the potential to cause classloader leaks, while they also provide a means to avoid them.

Uncleared ThreadLocals

As we talked about in the previous post, you should always call remove() on a ThreadLocal in a finally block.

Unstopped threads

In part III of this series we talked about the importance of making sure threads started within your web app stop executing when the application is redeployed.

JDBC driver included in WAR

Your JDBC driver will be registered in java.sql.DriverManager, which means that if you include your JDBC driver inside your web application, there will be a reference to your webapps classloader from system classes (see part II). The simple solution is to put JDBC driver on server level instead, but you can also deregister the driver at application shutdown.

Logging frameworks

Logging frameworks such as Apache Commons Logging (ACL) – formerly Jakarta Commons Logging (JCL) – log4j and java.util.logging (JUL) will cause classloader leaks under some circumstances.

Apache Commons Logging will cause trouble if the logging framework is supplied outside of the web application, such as within the Application Server. In such a case, you need to add a bit of cleanup code to the ServletContextListener we’ve talked about:




There is an article about this on the Apache Commons Wiki. It is also mentioned in the guide and FAQ.

When it comes to log4j, you can achieve the same kind of leak with some configurations. I’m not sure if calling org.apache.log4j.LogManager.shutdown() in the cleanup ServletContextListener helps, but it’s probably a good idea anyway, at least if there is only a single web application running on the server.

With log4j2, it seems the shutdown mechanism is a bit more complicated. I hope to get back with a more proper solution, but for now see this Stac kOverflow answer.

As for java.util.logging (JUL), it will always be outside the web application, since it is part of the JDK. With it you can cause classloader leaks by creating custom log Levels inside your web app. This is what Frank Kieviet uses as example in his blog post on classloader leaks. It seems also that JBoss Logging does exactly that if backed by JUL, and thereby triggers such a leak if loaded within your web app. See report here.

There is also a thorough article about the problem with logging frameworks and classloaders here. As a general recommendation, SLF4J supposedly helps preventing at least some of these problems.

Bean instrospection

The Java Bean introspection has a cache with strong references, that need to be cleared by calling


in the cleanup ServletContextListener. If you don’t want to create your own, you can use org.springframework.web.util.IntrospectorCleanupListener from the Spring framework.

Custom property editor

If a property editor loaded within the web application (or a property editor for a class loaded in the web application) is registered by calling java.beans.PropertyEditorManager.registerEditor() it needs to be deregistered at application shutdown, or it will cause classloader leaks. Deregistering can be achieved by calling java.beans.PropertyEditorManager.registerEditor() again with the same targetType but null as the second argument (editorClass).

Custom default

Custom loaded in your web application and registered with must be unregistered at application shutdown, or it will cause leaks.

Custom default

Custom loaded in your web application and registered with must be unregistered at application shutdown, or it will cause leaks.


Custom loaded in your web application and registered with must be unregistered with at application shutdown, or it will cause leaks. However, there is also a problem with javax.crypto.JceSecurity that holds a couple of static caches. So in case you’ve used a custom for cryptographic operations, this will cause a leak even if you call

Custom MBean

Custom MBeans registered in the MBeanServer (ManagementFactory.getPlatformMBeanServer().registerMBean()) needs to be unregistered at application shutdown, or they will cause leaks.

Custom MBean NotificationListener/NotificationFilter/handback

MBeans/MXBeans implementing the interface – or the sub-interface – may have added to them, in combination with a and/or a handback object. If any of these three are loaded by your web application, you would need to call removeNotificationListener() on shutdown to prevent leaks. Apache Pig has such a leak reported, but users are adviced to remove Pigs SpillableMemoryManager from the MemoryMXBean on application shutdown.

Undestroyed custom ThreadGroup

ThreadGroups are in a hierarchy with the “system” ThreadGroup at the top. Children are added to a parent upon creation, and parents will keep a reference to it’s child ThreadGroups, until the child is destroyed by a call to destroy(). This means that if java.lang.ThreadGroup is subclassed, and that subclass is loaded inside your application and instantiated, then there will be a strong reference to your applications classloader until that ThreadGroup is destroy()ed.

Known offenders

Among the API:s that are known to cause classloader leaks, without providing a proper cleanup/workaround, are a couple of JDK classes with the habit of keeping a reference to the contextClassLoader of the Thread that first calls them. The solution in this case is to make sure these methods are called once, with some other classloader – such as ClassLoader.getSystemClassLoader() – as contextClassLoader. Preferrably we put this code in the contextInitialized() method of our ServletContextListener. See Tomcats JreMemoryLeakPreventionListener class for more details.

Apache ActiveMQ

Apache ActiveMQ registers org.apache.activemq.util.StringArrayEditor as a property editor for String[] in java.beans.PropertyEditorManager (by a static block in org.apache.activemq.util.IntrospectionSupport), but provide no means of deregistering it. Reported here.

Apache Axis

Apache Axis leaks classloaders because of uncleared ThreadLocal, at least version 1.4, as we saw in part IV.

Apache Batik

Some versions of Batik SVG Toolkit (at least 1.5 beta 4 up to 1.7), leaves unterminated threads, as we saw in part III. It has been reported but at the time of this writing there is still no fix.

Apache Commons Pool / DBCP

Apache Commons Pool, which is used by Apache Commons DBCP, has a feature to automatically evict idle objects, which use a background thread running in the applications classloader. Earlier versions suffered from a bug, that did not allow the thread to be stopped properly (missing synchronization or volatile, like talked about in part III). See this blog post. It seem that in recent versions you can simply call org.apache.commons.pool2.impl.GenericObjectPool.close() at application shutdown. You can also turn off the idle evict feature at any time by calling org.apache.commons.pool2.impl.GenericObjectPool.
with a negative value.

Apache Commons HttpClient

Apache Commons HttpClient has a MultiThreadedHttpConnectionManager on which you may need to call the static shutdownAll() method in order to stop its ReferenceQueueThread, in case it has been loaded in your web app. This leak may be triggered by the Jersey jersey-apache-client.

Apache CXF

Apache CXF may set org.apache.cxf.transport.http.CXFAuthenticator as the default; see above. (Thanks to Arild Froeland for the report!) Reported here.

Bean Validation API / JSR 303

The Bean Validation API / JSR 303 will leak classloaders, if the API is at the application server level while the implementation, such as Hibernate Validator, is included inside your web application. More details in part II.

CGLIB / Hibernate / Spring / JBoss / Apache Geronimo

CGLIB, used by Hibernate, Spring etc, has had a bug in it’s proxy code, with uncleared ThreadLocals (see part IV). Bug report on Hibernate. Bug reports on Spring. Bug report on JBoss. Bug report on Apache Geronimo.


dom4j has uncleared ThreadLocals (see part IV). Reported here. That bug report is still “open”, but on other parts of the net report it to be fixed in 1.6.1.

DOM normalization/serialization

Two very similar issues can be triggered by creating a DOM document, and then either normalize it or serialize it, such as the following code

import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;

Document document = DocumentBuilderFactory.newInstance()

// or
DOMImplementationLS implementation = 

The reason for the potential leak is that both and have a static field named abort, each containing a RuntimeException whose stack trace may contain a reference to the first class that invoked the normalization/serialization. Reported here.


The contextClassLoader of the thread loading the com.sun.jndi.ldap.LdapPoolManager class may be kept from being garbage collected, since it will start a new thread if the system property com.sun.jndi.ldap.connect.pool.timeout is set to a value greater than 0.


The EclipseLink JPA implementation has had classloader leaks. According to this bug report fixed since version 1.1.


GeoTools is reported here to have unending thread. As of version 2.6.2 you should call org.geotools.util.WeakCollectionCleaner.exit() in your cleanup.

Google Guice

Googles IoC/DI framework Guice seems to have had several classloader leaks, at least some of which are not resolved at the time of this writing. Reports here, here and here.


Groovy can cause classloader leaks according to this bug report, which is still “open”.


Hessian binary web service protocol has suffered from uncleared ThreadLocals (see part IV). Bug reported here. Should be fixed since version 4.0.23 shipped with Resin.


iCal4J seems to have sufferend from uncleared ThreadLocals (see part IV). More info here.


Infinispan has had a number of reports of uncleared ThreadLocals. Two examples here and here, but there are more if you look at “Similar Issues” or search Jira yourself.


IntrospectionUtils copied from Tomcat (org.apache.tomcat.util.IntrospectionUtils) to Apache Commons Modeler (org.apache.commons.modeler.util.IntrospectionUtils) keeps a strong reference cache. After this was reported as a bug, a static clear() method has been added. Make sure to call it on application shutdown.


In case Jackson is included within the application server but used in a web application, com.fasterxml.jackson.databind.type.TypeFactory.defaultInstance().clearCache() should be called when that application is shutting down to avoid leaks. Reported here. Report against Wildfly, where Jackson is included, here.

Java Advanced Imaging (JAI)

Java Advanced Imaging (JAI) library can cause classloader leaks with registered shutdown hooks, as we saw in part II. Bug report here – still “open”.


The first calll to java.awt.Toolkit.getDefaultToolkit() will spawn a new thread with the same contextClassLoader as the caller.


I’ve seen reports on the net about PermGen errors when using older versions of Javassist for example with Hibernate. There are lots of issues in Javassist JIRA; start here and see “Similar Issues”. Since the issues have different fixed versions, you better use the latest version.

Java Cryptography Architecture (JCA) / MessageDigest initialization

According to Tomcat documentation, a Token poller thread with the same contextClassLoader as the caller, will be created “under certain conditions” when Java Cryptography Architecture is initialized, for example when a MessageDigest is created.

Java Server Faces 2

The JSF API, more precisely javax.faces.component.UIComponentBase, contains a cache that may cause classloader leaks in case the API is at the application server level. More information in this bug report.

javax.imageio / sun.awt.AppContext.getAppContext() / GWT

There will be a strong reference to the classloader of the calls to sun.awt.AppContext.getAppContext(). Note that Google Web Toolkit (GWT) will trigger this leak via its use of javax.imageio. Another way to trigger this leak is by creating a new javax.swing.JEditorPane("type", "text"). / sun.misc.GC.requestLatency(long)

sun.misc.GC.requestLatency(long), which is known to be called from, will cause the current contextClassLoader to be unavailable for garbage collection.

If the package is used together with a keystore that contains certificates that have unparseable extensions, there will be a reference from system classes to the exception occurring while trying to parse the extension. The backtrace (stacktrace) of that exception is likely to contain references to the code that called the classes. In a servlet environment this means the first webapp instance to trigger will be prevented from being garbage collected. Reported to Oracle here. Prevented since version 2.1.0. Thanks to “CptS” for the report! will keep a strong static reference to the contextClassLoader of the first calling thread.

The class will keep a strong static reference to the contextClassLoader of Thread from which the class is loaded.


JGroups may cause classloader leaks due to undestroyed custom ThreadGroups. At the time of this writing this issue has been fixed, while this one has not.


The no longer maintained LambdaJ seems to suffer from uncleared ThreadLocals in some cases.


Logback causes classloader leaks when using SocketAppender according to this report, in which is it not really clear whether it has been fixed.

Logback also seems to have suffered from uncleared ThreadLocals (see part IV), as of this report. However that should be fixed since version 0.9.26.


javax.xml.bind.DatatypeConverterImpl in the JAXB Reference Implementation shipped with JDK 1.6+ will keep a static reference (datatypeFactory) to a concrete subclass of javax.xml.datatype.DatatypeFactory, that is resolved when the class is loaded (which I believe happens if you have custom bindings that reference the static methods in javax.xml.bind.DatatypeConverter). It seems that if for example you have a version of Xerces inside your application, the factory method may resolve org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl as the implementation to use (rather than shipped with the JDK), which means there will a reference from javax.xml.bind.DatatypeConverterImpl to your classloader.


If the Mojarra JSF implementation is provided by the application server, and you have JSF components included in your .war file, Mojarra may cause classloader leaks by keeping references to the components when application is redeployed. See bug report here.


If JAXB implementation EclipseLink MOXy is included on the application server level, as is the case for at least some WebLogic versions, and then used within a web application, it may cause leaks. See bug report here.

Mozilla Rhino

The Rhino JavaScript interpreter has suffered problems related to ThreadLocals. You can read about the details in this blog post. The bug report states that it’s fixed (supposedly in 2005), but not from which version.


MVEL expression language enginge has problems with uncleared ThreadLocals. The problem was adressed but version 2.0.19 still leaks, due to a static block adding an MVEL class as a ThreadLocal value. Current bug report here.

OpenOffice Java Uno RunTime (JURT)

The JURT (Java Uno RunTime) library in the OpenOffice UDK contains a peculiar leak. In an effort to avoid OutOfMemoryErrors(!) caused by long-running finalize methods, they created the class, which holds a queue of jobs to be executed by a Thread. The problem is that this thread is never allowed to finish, as we talked about in part III. What makes this particularly tricky is that we don’t have any handle to the thread, and not least the fact that jobs are put on queue, and the thread is started if not yet running, from the finalize() method of other objects. That is, the thread may be started only when other objects are garbage collected, which may – at least in theory – not be until after your web application has been already unloaded! This problem has been reported here.

Oracle JDBC

Oracle JDBC driver, at least in some versions (such as ojdbc6), have a timeout detection thread, oracle.jdbc.driver.OracleTimeoutPollingThread, that according to reports has as its context classloader the classloader of the web application from which the first JDBC connection is requested, even if the driver itself resides on the server level. It seem this can be prevented by loading the class oracle.jdbc.driver.OracleTimeoutThreadPerVM using the system classloader before any JDBC connections are opened, which can be achieved in contextInitialized() of our ServletContextListener. (Thanks to Hal Deadman for the report!)

Postgresql JDBC

Postgresql JDBC driver will under some circumstances start timer threads with names prefixed PostgreSQL-JDBC-SharedTimer-. These threads may prevent your classloader from being garbage collected, presumably due to the inheritance of the context classloader and access control context. This has been reported here, but at the time of writing it is unclear if this is actually fixed or not. (Thanks to Hal Deadman for the report!)

SAAJ (SOAP with Attachments API for Java)

In the Sun/Oracle implementation of SAAJ, the class com.sun.xml.internal.messaging.saaj.soap.EnvelopeFactory has a cache of javax.xml.parsers.SAXParsers per context classloader. The classloader key is a proper weak reference, but in case the SAXParser or any of its properties/attributes are loaded by the very same classloader, it means there is a strong reference path from a system class to this classloader, which will prevent it from being GC:ed. For an example, where this could be avoided by resetting the SAXParser after use, see here. (Thanks to Samuel Brezáni for the report!)


Up to Java 1.4.2, serialization of classes loaded by your web apps classloader would cause reference to your classloader most likely to be kept by internal JDK caches. More info in this blog post. Bug report here.

Spring framework

Springs use of InheritableThreadLocal has caused leaks. Fixed since 1.2.9 / 2.0.1.


Loading the class sun.java2d.Disposer will spawn a new thread with the same contextClassLoader. More info. Fixed in Java 7.

In order to close reusable HTTP 1.1 connections after a timeout, starts a thread which will keep a strong reference to the classloader from which the HTTP connection was initiated (through a ProtectionDomain). See more info in this blog post. According to Magnus Alvestads article, the thread will terminate eventually, which may cause intermittent classloader leaks. If you have control over the server end you could add “Connection: close” to the HTTP responses. On the client end you can disable keep alive using -Dhttp.keepAlive=false.

Unified Expression Language

Up until version 2.2, the javax.el.BeanELResolver class of the Java Unified Expression Language / javax.el API kept a static strong reference cache with bean classes that had been introspected. This was reported as a leak and has since been fixed in version 2.2.4+ by using soft references in the cache. For currently released versions, the authors have been kind enough to provide a purgeBeanClasses() method to clear the cache, however this method is both private and non-static… (The JavaDoc of the method is a bit of a funny read, as it suggests the authors realized the problem, but failed to provide a proper solution.)


The caching mechanism of JarURLConnection can prevent JAR files to be reloaded. See this bug report. It is not entirely clear whether this will actually leak classloaders.

XML parsing

The classloader of the first thread to call DocumentBuilderFactory.newInstance().newDocumentBuilder() seems to be unable to garbage collection. Is it believed this is caused by some JVM internal bug.

Your Application Server

Yes, unfortunately the Application Server itself can be the cause of your classloader leaks. Tomcat (reports here, here, here), Jetty (here) and Resin (reports here, here, here, and more) has been know to suffer from such bugs, but there may be others as well. (There is a report on GlassFish here, but it’s not clear whether the error was actually within GlassFish.)

Pick the right Garbage Collector

It seems that for some reason, the default Garbage Collector of the Sun/Oracle JVM is not your best bet when it comes to freeing up permanent generation space. Assuming you have a multi core/multi CPU server (and who doesn’t these days?) I suggest you consider the Concurrent Mark and Sweep (CMS) Garbage Collector instead (but make sure you read up on the implications first). The CMS Garbage Collector however needs to be explicitly told to unload classes from PermGen space. Use these JVM options:

-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled

Depending on your JVM version, you may also need -XX:+CMSPermGenSweepingEnabled. Try them out and keep an eye on the console/log file during startup to see if the JVM accepts them.

For further reading on different Garbage Collectors, see here.

Links to all parts in the series

Part I – How to find classloader leaks with Eclipse Memory Analyser (MAT)

Part II – Find and work around unwanted references

Part III – “Die Thread, die!”

Part IV – ThreadLocal dangers and why ThreadGlobal may have been a more appropriate name

Part V – Common mistakes and Known offenders

Part VI – “This means war!” (leak prevention library)

Presentation on Classloader leaks (video and slides)