Search code examples
memory-leaksclassloaderjmeterapplication-server

Java Class Loader Leaks - Next Steps?

We are trying to get an HP UX server up for running some Batch Jobs in Java. The problem in the nutshell is this:

These Batch Jobs are running on the Jeus Application Server (a Made in Korea product). Although most of the jobs are running on time, some Batch Jobs have reported the famous PermGen Out of Memory Error. We got a heap dump and started looking at the JVM options. They are as follows: Xms - 2048m Xmx - 2048m PermSize - 512m MaxPermSize - 512m. The old GC collector is CMS and the young generation collector is a Parallel Collector.

We noticed that the actual Heap size is quite fine and that the PErm Gen ran out of all its 512m of memory. HPJmeter showed that this was a gradual rise in the memory and hence, we suspected a memory leak. We looked at all the Class Loaders and there were about 168 instances of the core Jeus App Server ClassLoader. The memory leak estimator showed that the this Class Loader was leaking memory. It showed that the number of bytes held were only around 3MB.

We looked at the number of classes/types loaded by this class loader and there were around 512 items. The memory leak also showed some other objects as being involved in memory leaks.

I have the following questions:

  1. Now that the Classloader which is leaking has been identified, how do we identify the exact reference(s) which is causing the problem?
  2. If one class loader with a specific object id is shown as leaking memory, is it possible that the other instances of the same class loader leak the some varying amount of memory?
  3. Any guidance as to what to do next would be highly appreciated.

Aditya.

Solution

  • Are you sure it's the class loader that's "leaking", or are the classes loaded by the loader still referenced?

    Understand that a "user class loader" is typically used to load classes that may need to be unloaded at a later time. Eg, if classes are dynamically generated as some sort of web page generation scheme, these classes need to be loaded within their own class loader, used, and then all traces of references to the classes and their loaders need to be eliminated. When those references are gone the loaders and loaded classes will be collected.

    If some sort of cache is hanging on to references to the classes (eg, by referencing objects of the classes, or by linking to the classes from other classes in other loaders) then collection doesn't occur.