Memory leaks, heap dumps and OOM errors

Memory leaks in Java are objects that a program no longer needs but still references, so the garbage collector, which reclaims only objects nothing can reach, has to keep them. The heap left over after each collection creeps up, collections come more often, and in the end the JVM throws OutOfMemoryError. Two kinds of evidence find the leak. A class histogram, printed by jcmd <pid> GC.class_histogram, counts the objects of every class, and two histograms taken some time apart show which classes grow. Heap dumps, written by jcmd <pid> GC.heap_dump, record every object and every reference, so a dump analyser can follow the chain of references that keeps the growing objects alive. When the memory does run out, the error’s message names which kind of memory it was. Heap dumps show chains like the one in this diagram for every object in the heap. Two more tools help: -XX:+HeapDumpOnOutOfMemoryError writes a dump at the moment of failure, and JDK Flight Recorder’s old-object sampler records the chain behind a few long-lived objects.

Four patterns behind most memory leaks

Most memory leaks in Java code follow one of four patterns, and each one is a reference that lives longer than the object it points to needs to:

• A static collection that only grows. A static field lives as long as its class, usually as long as the program, so everything added to it stays.
• A cache without a limit or a useful key. A map keyed by something that never repeats, such as a request id, stores one entry per request and never reads any of them again.
• Listeners and callbacks that are never removed. An event source holds every listener registered with it, and a listener that captures a page or a session keeps that alive too.
• ThreadLocal values on pooled threads. A thread holds its thread-local values while it is alive, and the threads of a pool live as long as the pool.

A leak reproduced with a 64 MB heap

This price service caches every quote under the id of the request that asked for it. Every request has a new id, so no entry is ever read twice or removed:

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.HashMap;
import java.util.Map;

/**
 * A price service that keeps every quote it has ever served. Each line of standard input is a batch size: the service
 * answers that many requests, each with a new request id, then prints how many quotes it holds.
 */
public class QuoteService {
    record Quote(String sku, long pricePaise, byte[] terms) {}

    // The leak: the cache is keyed by request id, and every request has a new id, so no entry is read twice or removed.
    static final Map<String, Quote> CACHE = new HashMap<>();
    static long served;

    static Quote quote(String requestId, String sku) {
        return CACHE.computeIfAbsent(requestId, id -> new Quote(sku, 49_900, new byte[1_000]));
    }

    public static void main(String[] args) throws Exception {
        var in = new BufferedReader(new InputStreamReader(System.in));
        for (String line; (line = in.readLine()) != null; ) {
            long batch = Long.parseLong(line.trim());
            for (long i = 0; i < batch; i++) {
                served++;
                quote("req-" + served, "SKU-" + served % 500);
            }
            System.out.println(served + " requests served, " + CACHE.size() + " quotes cached");
        }
    }
}

from session import run

# The leaking service with a 64 MB heap: 100 batches of 10,000 requests, more than the heap can hold.
# -XX:+ExitOnOutOfMemoryError makes the JVM exit at the first OutOfMemoryError, with exit status 3.
run("""
javac -d out QuoteService.java
yes 10000 | head -n 100 | java -Xmx64m -XX:+ExitOnOutOfMemoryError -cp out QuoteService
""", expect_failure=["yes 10000 | head -n 100 | java -Xmx64m -XX:+ExitOnOutOfMemoryError -cp out QuoteService"])

# JDK in use: openjdk version "25.0.4.1" LTS
$ javac -d out QuoteService.java
$ yes 10000 | head -n 100 | java -Xmx64m -XX:+ExitOnOutOfMemoryError -cp out QuoteService
10000 requests served, 10000 quotes cached
20000 requests served, 20000 quotes cached
30000 requests served, 30000 quotes cached
40000 requests served, 40000 quotes cached
50000 requests served, 50000 quotes cached
Terminating due to java.lang.OutOfMemoryError: Java heap space
[exit status 3]

The service answered 50,000 requests in this run, and the JVM stopped at the first OutOfMemoryError because -XX:+ExitOnOutOfMemoryError tells it to, with exit status 3. The failure point can be estimated before running it. Each request leaves behind a 1,000-byte array (1,016 bytes with its header), two short strings for the request id and the SKU (about 50 bytes each, with their arrays), a map entry of 32 bytes and a Quote of 32 bytes: about 1,180 bytes. A 64 MB heap holds about 57,000 of those, and the service died between 50,000 and 60,000 requests.

Two class histograms, 20,000 requests apart

One histogram is a list; two are evidence. This session starts the service in one terminal, sends it batches of requests, and takes a class histogram from a second terminal after each batch:

from session import background, read, run

# Two class histograms of the leaking service, 20,000 requests apart, and what grew between them.
run("javac -d out QuoteService.java")
print("# Terminal 1: the service, with a 64 MB heap. Each line typed is a batch of requests.")
service = background("java -Xmx64m -cp out QuoteService")
service.send("20000")
print("# Terminal 2: find the process, then save a class histogram")
run("""
jcmd -l | grep QuoteService
jcmd <pid> GC.class_histogram > before.txt
head -n 7 before.txt
""", version=False)
print("# Terminal 1")
service.send("20000")
print("# Terminal 2")
run("""
jcmd <pid> GC.class_histogram > after.txt
head -n 7 after.txt
""", version=False)
print("# Terminal 1")
service.close()


def rows(text):
    """Class name -> (instances, bytes), from the rows of a histogram ("   1:   77378   22293936  [B (java.base@25)")."""
    out = {}
    for line in text.splitlines():
        parts = line.split()
        if len(parts) >= 4 and parts[0].endswith(":") and parts[0][:-1].isdigit():
            out[parts[3]] = (int(parts[1]), int(parts[2]))
    return out


before, after = rows(read("before.txt")), rows(read("after.txt"))
growth = sorted(((after[c][1] - before.get(c, (0, 0))[1], after[c][0] - before.get(c, (0, 0))[0], c) for c in after), reverse=True)
print("# What grew between the two histograms: the five largest increases, in bytes")
for added_bytes, added, name in growth[:5]:
    print(f"{added:+10,} instances {added_bytes:+14,} bytes  {name}")

# JDK in use: openjdk version "25.0.4.1" LTS
$ javac -d out QuoteService.java
# Terminal 1: the service, with a 64 MB heap. Each line typed is a batch of requests.
$ java -Xmx64m -cp out QuoteService
> 20000
20000 requests served, 20000 quotes cached
# Terminal 2: find the process, then save a class histogram
$ jcmd -l | grep QuoteService
<pid> QuoteService
$ jcmd <pid> GC.class_histogram > before.txt
$ head -n 7 before.txt
<pid>:
 num     #instances         #bytes  class name (module)
-------------------------------------------------------
   1:         68559       21753032  [B (java.base@25.0.4.1)
   2:         48480        1163520  java.lang.String (java.base@25.0.4.1)
   3:         21013         672416  java.util.HashMap$Node (java.base@25.0.4.1)
   4:         20000         640000  QuoteService$Quote
# Terminal 1
> 20000
40000 requests served, 40000 quotes cached
# Terminal 2
$ jcmd <pid> GC.class_histogram > after.txt
$ head -n 7 after.txt
<pid>:
 num     #instances         #bytes  class name (module)
-------------------------------------------------------
   1:        128559       43193032  [B (java.base@25.0.4.1)
   2:         88480        2123520  java.lang.String (java.base@25.0.4.1)
   3:         41013        1312416  java.util.HashMap$Node (java.base@25.0.4.1)
   4:         40000        1280000  QuoteService$Quote
# Terminal 1
> (end of input)
# What grew between the two histograms: the five largest increases, in bytes
   +60,000 instances    +21,440,000 bytes  [B
   +40,000 instances       +960,000 bytes  java.lang.String
   +20,000 instances       +640,000 bytes  java.util.HashMap$Node
   +20,000 instances       +640,000 bytes  QuoteService$Quote
        +0 instances       +131,072 bytes  [Ljava.util.HashMap$Node;

jcmd -l lists the JVMs running on the machine, with their process ids and main classes; jcmd works only on the same machine, as the user who started the JVM. GC.class_histogram counts only live objects unless you add -all, then prints one row per class: instances, bytes and the class name ([B is byte[]). Between the two histograms, the 20,000 new requests added exactly 20,000 QuoteService$Quote objects, 20,000 map entries, 40,000 strings and 60,000 byte arrays: three arrays per request, one for the terms and one inside each string. Whatever grows by a fixed amount per request, and never shrinks, is the leak. The other rows tell you less: the JDK’s own objects show up in every histogram and change little.

What each OutOfMemoryError message points to

The message after java.lang.OutOfMemoryError: names the memory that ran out. OOM errors, as these errors are usually called, come in seven common kinds, each with its own limit and its own first check:

Check yourself

Heap dumps and the path to a leak, step by step Pro: opens with a Pro, Premium or Ultimate pass

Each OutOfMemoryError reproduced, with the fix that holds Pro: opens with a Pro, Premium or Ultimate pass

Fixing the leak, proving the fix, and a leak to find yourself Pro: opens with a Pro, Premium or Ultimate pass

Interview questions

Key takeaways

• A leak is a reference that outlives its use; the collector cannot reclaim anything that is still reachable.
• Two class histograms taken some time apart show which classes grow with the work: that row is the lead.
• A heap dump, or an old-object recording with path-to-gc-roots=true, shows the chain from the leaked object to the field that holds it.
• OOM errors name the memory that ran out in their message, and each kind has its own limit and its own fix.