Java has a garbage collector, so how can a Java program still leak memory?

## The core idea A **memory leak** is memory the program has allocated but can no longer use *and* can no longer reclaim. In manually-managed languages like C, a leak means you allocated memory with `malloc` and forgot to `free` it. In Java you never call `free` — the **garbage collector (GC)** does it for you — so leaks look different. ## What the garbage collector actually does The GC's job is to find and delete objects that are **unreachable**. An object is **reachable** if you can get to it by starting at a **GC root** and following references (object-to-object pointers). **GC roots** are the starting points the collector trusts as 'definitely alive': - **static fields** of loaded classes, - local variables and parameters on the **stack of any live thread**, - active **JNI/native** references, - a few JVM internals. The collector does a **reachability analysis**: start at every root, walk every reference, mark everything you can touch as live. Anything *not* marked is unreachable and gets freed. This is the key rule: **the GC frees an object only when nothing reachable points to it.** ## So what is a Java leak? A Java leak is **unintended reachability**: an object you are logically done with is *still* reachable from some GC root, so the collector is *not allowed* to free it. The program no longer uses the object, but it cannot be collected because a reference is still hanging on somewhere. Note the asymmetry: you don't have to do anything 'wrong' like a double-free. You just have to **forget to drop a reference**. The leak is silent — the object sits in memory, fully retained, doing nothing. ## Why it grows Leaks matter when the unwanted-but-retained objects **accumulate over time**: every request adds an entry to a cache that is never evicted, every connection registers a listener that is never removed, every pooled thread leaves a value in a `ThreadLocal`. The **retained heap** (the total memory kept alive because of these references) climbs steadily. Eventually the heap fills, the GC works harder and harder for less and less free space, and you get an `OutOfMemoryError: Java heap space`. ## Classic leak patterns (rooted in reachability) Every pattern below is the same root cause — a reference from a long-lived GC root to a short-lived object: 1. **Unbounded static collections / caches** — a `static Map` or `List` that you only ever add to. Statics are GC roots, so everything in them is permanently reachable. 2. **Listeners / callbacks never deregistered** — you `addListener(this)` but never `removeListener`. The event source (often long-lived) keeps your object alive. 3. **ThreadLocals in pooled threads** — a thread-pool thread never dies, so a value you stored in a `ThreadLocal` and never `remove()`d stays reachable for the life of the pool. 4. **Unclosed resources** — streams, connections, and sessions that aren't closed keep buffers and native handles alive. ## How you detect and fix it **Detect:** watch for the heap's *live* (post-GC) size trending upward over time; capture a **heap dump** and look at which objects have the largest **retained size** and what GC-root path keeps them alive. **Fix:** make the object unreachable again — remove it from the collection, deregister the listener, call `ThreadLocal.remove()`, or close the resource (ideally with try-with-resources). Once no GC root can reach it, the next collection frees it. ## The mental model to carry away 'GC frees what you can't reach.' A leak is therefore **you keeping a reference you no longer want.** Find the unwanted reference, drop it, and the leak is gone.