How do you identify and fix a memory leak?

Hook: In Java, a memory leak is usually not missing free(); it is a forgotten reference that keeps objects alive, like a broom closet whose door is still bolted shut from the inside.

Question: How do you identify and fix a memory leak?

Answer: I first confirm that memory is being retained, not just used heavily during a spike. In Java, a leak usually means objects are still reachable through a strong reference (a normal reference that keeps an object alive), so the garbage collector cannot reclaim them. Then I use a heap dump, GC logs, or a profiler to find the retention path, fix the code that keeps the reference, and rerun the same load to prove the heap settles down.

Interview-Ready Answer: I would start by reproducing the problem under load and checking whether heap usage keeps rising after GC. Then I’d take a heap dump and look at the largest retained objects and their GC roots, because that tells me what is still holding them alive. Once I find the retention path, I fix the source — for example, a static collection, forgotten listener, or uncleared ThreadLocal — and I verify the fix by running the same test again and confirming the heap and GC pauses stay stable.

What a leak really is

A Java memory leak is almost always object retention: data that should be dead is still reachable from something alive. The garbage collector can only reclaim objects that are no longer reachable from GC roots — the starting points the JVM treats as live, such as thread stacks, static fields, JNI references, and active local variables.

How to find it, step by step

1. Confirm the symptom. Watch heap usage, GC frequency, and pause time. A real leak often shows a sawtooth pattern that never returns to the same baseline after GC.
2. Reproduce with a steady load. A leak is easier to see if you run the same request pattern for 10–30 minutes instead of guessing from one spike.
3. Capture evidence. Use jcmd <pid> GC.class_histogram for a quick snapshot, or take a heap dump with jmap -dump:live,format=b,file=heap.hprof <pid>. A heap dump is heavy, but it shows who is holding memory.
4. Inspect retained size. In tools like Eclipse MAT or VisualVM, look for the objects with the biggest retained size — the memory that would be freed if that object disappeared. Then follow the reference chain back to the root.
5. Fix the root cause, not the symptom. Common fixes are removing stale entries from maps, unregistering listeners, clearing ThreadLocal values in thread pools, bounding caches, and closing native resources.
6. Verify the fix. Run the same load again and check that heap usage stabilizes, full GCs stop piling up, and allocation rate matches your real traffic.

Tools: fast first look vs deep proof

Time-wise, a histogram is the cheapest first pass, a profiler usually adds low single-digit to low double-digit overhead, and a heap dump is the most expensive because it is roughly proportional to heap size. That is why interviewers like this question: the best engineers do not guess; they narrow the problem, prove the cause, and then verify the fix.

Important edge cases

• A big cache is not automatically a leak if it is bounded and intentional.
• A heap may look fine while RSS grows because of off-heap memory such as direct buffers or native libraries.
• ThreadLocal leaks are common in servlet and executor thread pools because threads live a long time.
• Class loader leaks happen in hot-reload systems when old classes stay reachable through static state or listeners.

Real-world story: In an e-commerce checkout service, each request stored a small session helper in a static map so later code could read it. During normal traffic it looked fine, but on a big sale the heap kept climbing, Full GC ran every few seconds, and the pods restarted with java.lang.OutOfMemoryError: Java heap space. The root cause was not the garbage collector; it was unbounded retention. The fix was to remove the static map, make the data request-scoped, and use a bounded cache with a TTL where persistence was actually needed.

What goes wrong when people misunderstand this: they add more heap and delay the failure, but p95 latency rises, logs fill with long GC pauses, and customers see timeouts at checkout.

Follow-up & Tricky Questions:

• How do you tell a leak from normal high memory usage? A leak keeps the baseline climbing after GC, while normal usage returns to a steady level after the workload passes.
• What tools do you reach for first? I usually start with GC logs and a class histogram, then move to a heap dump or MAT when I need the exact reference chain.
• How do you fix a ThreadLocal leak? Remove the value with remove() when the request is done, especially in thread pools where threads live much longer than the request.
• What is a GC root? It is a starting point the collector treats as live, such as a thread stack, static field, or JNI reference; anything reachable from it survives.
• How do you prove the fix worked? I rerun the same traffic pattern and compare retained heap, pause times, and allocation rate before and after the change.

Tricky question: Does calling System.gc() fix a memory leak? No. It may trigger a collection, but it cannot free objects that are still reachable through a live reference.

Tricky question: Is every large cache a leak? No. A bounded cache with an eviction policy is intentional; a leak is memory that should have been released but was accidentally kept.

Tricky question: Can a Java app leak memory even when the heap looks stable? Yes. Native memory, direct buffers, and class loader leaks can grow outside the normal heap view, so you may need native memory tracking or OS-level metrics too.

Common Mistakes:

• Blaming the GC first. Correction: the GC is usually doing its job; something is still holding references.
• Watching only free memory. Correction: track retained heap, GC frequency, and pause time over time, not one snapshot.
• Fixing symptoms with bigger heaps. Correction: more heap only delays the outage; it does not remove the root cause.
• Forgetting non-heap leaks. Correction: check direct buffers, native code, and class loaders when the heap alone does not explain the growth.

Memory Hook: If one strong reference still points at it, the object is still invited to the party. GC can only clean up what nobody is reaching for.

Cheat Sheet:

• Leak = unexpected object retention, not a missing manual free.
• First prove the baseline keeps rising after GC.
• Use GC logs, histogram, then heap dump for the exact path.
• Look for static fields, listeners, caches, and ThreadLocal values.
• Fix the reference, not the symptom.
• Verify with the same load test and watch retained size drop.

Practice Tasks:

• Write a small program that adds objects to a static list and watch the heap grow.
• Change it to clear the list or make the data local, then compare memory after GC.
• Simulate a listener leak in a thread pool and fix it with proper unregistering or ThreadLocal.remove().