How Do Memory Leaks Happen in Java?

A Java memory leak is memory that the garbage collector cannot reclaim, because it is still reachable. The collector is doing its job correctly; the problem is that something in the program still holds a reference to an object nobody wants any more.

The causes, in rough order of how often you will meet them. Unbounded collections. A cache or a list that grows forever and is never trimmed. This is the most common cause by a wide margin, and the fix is an eviction policy rather than a bigger heap. Listeners that are never removed. Registering a listener on a long-lived object and never deregistering it keeps the listener, and everything it references, alive. Static collections holding objects that should have died. Thread locals that are never removed, particularly in a thread pool where the thread outlives the request. And class loader leaks, where a class loader stays reachable because something it loaded is still reachable, which in turn keeps all of that loader's classes in Metaspace alive.

The pattern worth naming is the retained size versus the shallow size. A single small object can retain a huge object graph if it holds a reference to a list of a million entries. That is why a leak often looks like a small number of objects in a heap dump but a large amount of memory.

The other thing to understand is that a leak in Java usually shows up as a slow growth over hours or days rather than an immediate failure. The application gets slower as the collector works harder, and eventually it fails with an OutOfMemoryError — often in a completely unrelated place, because the memory ran out when something else tried to allocate.

Here is the same thing as runnable code:

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        Runtime runtime = Runtime.getRuntime();

        // A static collection that keeps growing: a classic leak.
        List<String> cache = new ArrayList<>();
        for (int i = 0; i < 100_000; i++) {
            cache.add("entry " + i);
        }
        System.out.println("cache size    : " + cache.size());
        System.out.println("used heap MB  : " + usedMb(runtime));

        // Clearing the reference lets the collector reclaim it.
        cache.clear();
        System.out.println("after clear   : used heap: " + usedMb(runtime) + " MB");
        System.out.println("the collector decides when to run");
    }

    static long usedMb(Runtime runtime) {
        return (runtime.totalMemory() - runtime.freeMemory()) / (1024 * 1024);
    }
}

The process is always the same three steps: measure, take a heap dump, and compare two dumps. The comparison is the key, because a single dump tells you what is big but not what is growing.

Measure first. The memory MX beans give you the heap usage over time, and in a running service the pattern is the clue. A sawtooth that gets wider means the collector is working harder. A baseline that ratchets upwards between collections means something is being retained. And getNonHeapMemoryUsage tells you whether the growth is in Metaspace, which points at a class loading problem rather than an object leak.

public class Main {
    public static void main(String[] args) {
        java.lang.management.MemoryMXBean memory =
                java.lang.management.ManagementFactory.getMemoryMXBean();
        System.out.println("heap used  : " + memory.getHeapMemoryUsage().getUsed() / (1024 * 1024) + " MB");
        System.out.println("heap max   : " + memory.getHeapMemoryUsage().getMax() / (1024 * 1024) + " MB");
        System.out.println("non-heap   : " + memory.getNonHeapMemoryUsage().getUsed() / (1024 * 1024) + " MB");

        // Every pool has its own usage.
        for (java.lang.management.MemoryPoolMXBean pool
                : java.lang.management.ManagementFactory.getMemoryPoolMXBeans()) {
            System.out.println("pool : " + pool.getName()
                    + " -> " + pool.getUsage().getUsed() / (1024 * 1024) + " MB");
        }
    }
}

The output shows the heap and non-heap figures and the per-pool breakdown. The pool names tell you which generation is growing — the Eden and survivor pools point at allocation rate, the old generation points at retention.

Take a heap dump. Use jcmd or the diagnostic management bean, and open it in a heap analyser. Look at the dominator tree, which shows the objects that retain the most memory, and then follow the references from the dominator back to your code. That path is the leak.

Compare two dumps. Dump once, put the system under load, dump again, and look at what grew. The objects whose count increased between the dumps are the leak.

Two practical warnings. A dump briefly stops the application, so on a large heap take it on a replica or during a quiet window. And a heap dump only shows what is strongly reachable — if the leak is through a soft or weak reference you will need a dump that forces those to be collected first.