Java Memory Leaks et al. (2. Act)


The first act of this blog-series Java OutOfMemoryError – A tragedy in seven acts described the architecture of JVM memory and discussed where a java.lang.OutOfMemoryError could occur.

So let’s have a detailed look on how this error can actually happen in a Java application.

In the previous post, we saw multiple possible types of the OutOfMemoryError. But the one happening most of the time is this one:

Exception in thread "main": java.lang.OutOfMemoryError: Java heap space

The error indicates that there has not been enough free heap to fulfill an allocation request for a new object. In other words: there is no room for the object on the heap. Since, according to the JVM specification, every heap has to have a garbage collector, this also means that no memory was freeable by it. So the whole memory is filled with “live” objects.

To understand how this can happen, it is important to understand what a “live” object actually is.

In Java objects get generated on the heap and live on as long as they are referenced. The garbage collector checks during it GC-phases if the object is still referenced – and does mark it as “garbage” and clean it up later when this is no longer the case (the actual behaviour differs for different gc-algorithms, like the Copying Collectors or Garbage-First, but is not of importance for understanding liveness). But not every reference is important for surviving, but only so called GC root references. Especially when understanding Memory Leaks, GC roots are a central concept to identify the important references to an object. Garbage Collector Roots are special objects which do not have incoming references and are responsible for keeping referenced objects alive. When an object cannot be reached directly or indirectly from a GC root, it will be marked as “unreachable” and made eligible for garbage collection. Simply speaking, there are three kinds of GC roots:

• Temporary variables on the stack of a thread

• Static members of a loaded class

• Special native references from JNI

Here an example which shows where GC Roots play a role for a class:

public class MyFrame extends javax.swing.JFrame {
  // reachable via Classloader as soon class is loaded
  public static final ArrayList STATIC = new ArrayList();
  // as long as the JFrame is not dispose()'d,
  // it is reachable via a native window
  private final ArrayList jni = new ArrayList()
  // while this method is executing parameter is kept reachable,
  // even if it is not used
  private void myMethod(ArrayList parameter) {
    // while this method is running, this list is reachable from the stack
    ArrayList local = new ArrayList();

Usually there are tree types of issues with Java OutOfMemoryError problems in heap memory:

  • Objects, which can be reached via a GC root reference, but are actually no longer used by application code. Those are called Java Memory Leaks.
  • Too many or too large objects. So there is not enough heap available for the application to execute. Usually happens when there are large objects kept in cache like structures.
  • Too many temporary objects. So there is just for a short time not enough memory. Usually happens in load scenarios where many temporary objects are used.

Java Memory Leaks

So Java Memory Leaks occur when objects still have a GC root reference, but are not actually used anymore. Those “Loitering Objects” stay around for the whole life of the JVM. If the application is creating those “dead objects” on and on, the memory will be filled up and eventually result in a java.lang.OutOfMemoryError. Typical causes are static collections, which are used as a kind of cache. Usually objects are added, but never removed (Let’s face it: How often have you used add() and put() and how often used remove() methods?). Because the objects are referenced by the static collection, they cannot be freed up anymore, as the collection has a GC root reference via the classloader.

When discussing Memory Leaks one comes usually across the terms dominator or dominator tree. The dominator concept comes from graph theory and defines a node as dominator of another node when this node can only be reached via it. Applying this to memory management, object A is dominator for object B when there is no object C which holds a reference to B. A dominator tree is a partial tree in which this condition holds true for all nodes from the root node. When the root reference is freed, the whole dominator tree is freed as well. Large dominator trees are great candidates when looking for memory leaks.

Depending on the creation frequency and the object size, as well as the size of the Java heap, the OutOfMemoryError occurs sooner or later. Especially those “creeping memory leaks” can be found in many applications, but are usually “ignored” by:

  • Using large heaps to delay the error. Happens frequently nowadays, as the old 32bit memory limit has vanished through the usage of 64 bit JVMs.
  • Restarting the application server during the night. This “resets” the memory usage. If the memory leak takes longer than 24 hours to become severe, this will help.

But both variants are dangerous, as they have negative impact on the system performance and are heavily influenced by the system usage. A change in usage or more “traffic” can produce the error faster than expected. Garbage collection times also have a negative effect on the application performance, as the increasing “tenured generation” causes longer “Mark”-Phases during garbage collection, resulting in longer pause times, which can be observed as system hangs. Act 3 and 4 will describe analysis of those leaks in details and give advice on how to avoid them.

Too much memory

Besides Java memory leaks, there are is another reason for OutOfMemoryError: The application is just consuming too much memory. Either there is not enough heap configured and it has to be increased (also see part 3 of the series) or the consumption has to be throtteled, e.g. by shrinking cache sizes.

Especially critical is high temporary memory usage in enterprise applications, which can have a high number of concurrent users. Because it can happen out of the blue, this OutOfMemoryError is especially troublesome, as it cannot be countered with a nightly reboot. The following code illustrates the problem:

byte[] image = getTheByteImage();
ServletOutputStream out = response.getOutputStream();

While it is not that obvious, the code consumes memory on heap for each image before sending it to the browser. A much better variant would be to stream the image like this:

InputStream image = getTheImageAsStream();
ServletOutputStream out = response.getOutputStream();
IOUtils.copy(image, out);

(Of course BufferedStreams and IOUtils use byte[] internally as well, but this is much smaller)

Having covered only the java.lang.OutOfMemoryError problems in heap, I might dedicate another post to other areas, like the permanent generation as mentioned in the previous episode.

The next episode will be “Confguring and Monitoring the Java Virtual Machine”, which will show how to configure and optimize the Sun JVM and how to monitor it with the bundled tools.

“Creating and understanding Java Heapdumps“ will then be the fourth episode and describe how to handle Heapdumps. We will find out how to discover the causes of the Memory Leaks described here.

Also those two are going to be more practical oriented, so you can expect some screencasts.


  • Sandeep

    I understand that if you have an object created but no longer used until the exit of application. Its like blocking memory for objects which are used.

    But my question is:
    Are there scenarios where memory leaks occur because no reference is pointing (references) to an object.

    A sample program to demonstrate that would really help…

  • Paweł

    4. March 2011 von Paweł

    As far as I know you may try to “get” such memory leaks but only by using JNI.
    In pure Java you should never be able to produce such memory leaks (until GC is implemented properly).

  • Adam S.

    4. March 2011 von Adam S.

    Excellent article Mirko! I can’t wait to see the next part.

    Here is something I would like to see discussed in one of your articles. What are the best practices to handle OOM.

    I am not talking about application recovery from OOM (heap space). What I mean is to be able to detect from within the application OOM and some logging/notification/critical cleanup. How this can be successfully done if may not be allowed to allocate any more memory.

    It seems to be almost impossible to pre-allocate all objects we may require to handle OOM notification ? Or is it ? Is there a better way ?

  • Gautam Dev

    Excellent article. It is easy to forget the basic things.

  • Michael Benzinger

    5. March 2011 von Michael Benzinger

    One that just bit me recently that I didn’t really even consider when coding originally: doing a ByteBuffer.allocateDirect for every read instead of using a pool for them. It seems that the rules for garbage collection are different in this case.

  • h143570

    6. March 2011 von h143570

    Michael Benzinger: Direct buffers, like ByteBuffer.allocateDirect is not allocated on the heap. Because of this, they are excluded from GC. Direct buffers are actually allocated in the memory called Direct Memory. The following command line option can be used to change the size “-XX:MaxDirectMemorySize=”. It is available in JVM 1.5 or above.

    So you can get non GC able memory within the JVM. Which is actually can be used to create caches several hundred GB large. Without GC caused slowdowns.


Your email address will not be published.