How can code that uses only ordinary strong references still cause a memory leak in a garbage-collected JVM?

## 'Managed' does not mean 'leak-proof' Java has a **garbage collector (GC)** that reclaims objects you can no longer reach, so it prevents the C/C++ style of leak (forgetting to `free`). But the GC's rule is purely **reachability**: it keeps every object reachable from a **GC root** (an always-live anchor — thread stacks, static fields, etc.) through a chain of **strong references**, and frees the rest. A **Java memory leak** is therefore not a failure to free; it is **unintended strong reachability** — you keep a strong reference to something you will never use again, so the GC is *obligated* to keep it. Memory usage climbs (the leaked objects' **retained heap** grows) until the JVM throws `OutOfMemoryError: Java heap space`. The whole topic is the dark side of the strong-reference contract: the same rule that guarantees your live objects survive also guarantees your *accidentally-still-referenced* objects survive. ## Classic strong-reference leak patterns ### 1. Unbounded static collections / caches ```java static final Map<Key, Value> CACHE = new HashMap<>(); void handle(Key k) { CACHE.put(k, compute(k)); } // never removed ``` The `static` field is a GC root; everything it transitively holds is pinned forever. A cache with no eviction policy is the most common leak. Fixes: bound it (LRU, e.g. a size-limited map or a library cache), evict explicitly, or hold values via **soft/weak references** so the GC may reclaim them (`WeakHashMap`, soft-valued caches). ### 2. Listeners / callbacks never deregistered Register an observer with a long-lived publisher and forget to remove it: the publisher keeps a strong reference to the listener (and through it, often a whole UI screen or request context), so the listener — and everything it captures — never dies. Fix: always `removeListener` in the matching teardown, or hold listeners weakly. ### 3. ThreadLocals on pooled threads ```java static final ThreadLocal<Heavy> TL = new ThreadLocal<>(); TL.set(new Heavy()); // set during a request handled by a pool thread // ... never TL.remove() ``` In a thread pool, the **thread outlives the request**. The value stays strongly reachable via the thread's `ThreadLocalMap` for the life of the pooled thread, accumulating across requests. Fix: `TL.remove()` in a `finally` block. ### 4. Unclosed resources / lapsed-listener style holds Streams, connections, or buffers held open keep their backing objects (and sometimes native memory) reachable. Fix: `try-with-resources` / `AutoCloseable`. ## Why cycles are *not* the cause A common misconception is that reference cycles leak in Java. They do not: the GC uses reachability from roots, not reference counting, so an isolated cycle that no root can reach is collected. Every real Java leak traces back to a **live root** still strongly reaching the garbage. ## Diagnosing Because the leaked objects are validly reachable, the GC cannot help you; you must find *who* is holding the references: - Enable `-XX:+HeapDumpOnOutOfMemoryError`, or capture a dump with `jmap`. - Open it in **Eclipse MAT** or **VisualVM** and inspect the **dominator tree** and **retained size** to see which root is responsible for the bulk of retained heap, then follow the reference chain back to the offending field/collection. - Watch trends live with `jstat`, JFR, or VisualVM: a leak shows as retained heap that keeps rising after full GCs rather than returning to a baseline. ## The remedy in one sentence Every fix is the same shape: **break the unwanted strong reachability** — bound/evict, deregister, `remove()`, `close()`, or downgrade to a weaker reference type so the GC is allowed to reclaim the object.