How do you identify a memory leak?

Hook: Interviewers love this question because a real Java leak often looks like a slow GC problem long before it becomes an outage.

Question: How do you identify a memory leak?

Answer: In Java, a memory leak usually means objects are still strongly reachable, so the garbage collector cannot reclaim them. I identify it by watching for a heap that keeps rising over time, especially after a full GC, along with longer GC pauses or eventual OutOfMemoryError. Then I reproduce the workload, take a heap dump, and use a tool like Eclipse MAT to follow the retaining path from GC roots to the unexpected owner.

Interview-Ready Answer: I first confirm it is really a leak and not just normal allocation pressure. My rule of thumb is: after a full GC, used heap should drop and then settle; if it keeps climbing with the same traffic, that is suspicious. Then I capture GC logs and a heap dump, and I inspect the dominator tree and paths to GC roots in a tool like MAT to find what is holding the objects alive. If the heap looks fine but process memory still grows, I also check off-heap memory, direct buffers, and metaspace. The key idea is that a leak in Java is usually a retained reference, not just high memory usage.

What a Java memory leak really is

A Java leak does not mean the JVM has no garbage collector. It means some object is still reachable through a reference chain, so the GC must treat it as live. A classic beginner mistake is to think, 'memory went up, so it is a leak' — but sometimes the app is just handling a spike, building a cache, or allocating many short-lived objects.

How to identify it under the hood

1. Establish a baseline. Run the service under normal traffic and watch heap used, old generation usage, GC pause time, and allocation rate. A leak often shows a monotonic trend: after each GC cycle, the minimum used heap creeps upward instead of returning to the same level.
2. Compare after a full GC. A healthy app usually drops to a stable plateau after major GC. If the heap remains high or keeps climbing after full GCs, suspect retained objects. This is one of the strongest signals because it separates 'temporary pressure' from 'objects that never die.'
3. Capture evidence. Turn on GC logs and, if possible, JFR (Java Flight Recorder, a low-overhead runtime profiler). On Java 9+, use -Xlog:gc*; on Java 8, the classic flags are -XX:+PrintGCDetails -XX:+PrintGCDateStamps. Then capture a heap dump when memory is high, usually with jcmd <pid> GC.heap_dump /path/app.hprof. A live histogram with jcmd <pid> GC.class_histogram is a quick clue, but it is not enough to prove a leak.
4. Analyze retained size. In a heap dump, focus on retained size (how much memory would be freed if that object disappeared), not just shallow size (the object itself). In Eclipse MAT, the dominator tree helps you find the objects retaining the most memory. Then use paths to GC roots to answer the most important question: 'What is keeping this alive?'
5. Look for the common culprits. In Java, leaks often come from static collections, unbounded caches, ThreadLocal values that are never removed, listener lists, queues that grow faster than they drain, and classloader leaks in app servers. If memory is in direct buffers or other native memory, the heap dump may not explain the full process growth, so check native memory too.
6. Verify the fix with the same load. After you cap the cache, remove the listener, clear the ThreadLocal, or close the resource, rerun the same workload. A real fix changes the trend: the heap stops climbing and eventually reaches a stable steady state.

Leak vs normal growth vs native memory growth

One useful detail interviewers like: heap dump creation is roughly O(heap size) in time and disk I/O, so a 2-8 GB heap can take seconds to tens of seconds to dump, and several minutes to inspect well. JFR is usually low overhead for production, while a heap dump is more intrusive, so I prefer to observe live first, dump second.

Important edge cases

• A leak can hide in ThreadLocal because thread pools keep threads alive for a long time.
• A leak can come from a static field inside a utility class, which silently keeps an entire object graph alive.
• A 'stable' heap can still hide a leak if the app leaks in native memory, metaspace, or direct byte buffers.
• Do not trust System.gc() as proof of anything; it may trigger collection, but it cannot free objects that are still referenced.

Memory model to remember: the GC only removes what nobody can reach. If there is a path from a GC root to the object, it is still alive.

Real-world production story

Imagine a Java checkout service during a holiday sale. Traffic is normal at first, but after two hours the service gets slower, p99 latency rises, and logs show more frequent GC pauses. Eventually the app logs java.lang.OutOfMemoryError: Java heap space, and the pod is restarted by Kubernetes.

When the team takes a heap dump, MAT shows a large ConcurrentHashMap retained by a static singleton cache. The cache stores user session data keyed by token, but there is no eviction policy and no TTL (time to live, meaning entries expire after a set time). Every request adds more entries, so the heap never settles. The impact is visible to users: checkout requests time out, abandoned carts increase, and support sees complaints that the site is 'randomly' slow before it crashes.

The misunderstanding that causes the outage is thinking 'we have a cache, so memory growth is normal.' A good cache is bounded and deliberate; a leak is accidental and unbounded. The practical symptom is that memory usage keeps rising even when traffic level stays the same.

Follow-up & Tricky Questions:

• How do you tell a leak from normal allocation pressure? Check the heap after a full GC. A leak keeps the post-GC baseline climbing, while allocation pressure usually drops back down once the burst passes.
• Which tools do you use first in production? I start with GC logs and a quick histogram because they are low risk, then I take a heap dump if the trend is bad enough. If the heap looks normal but the process still grows, I check native memory tracking.
• What is a GC root? It is a starting point the GC can always reach, such as a static field, a live thread, or a JNI reference. If your object is reachable from a GC root, it will not be collected.
• How do you find a ThreadLocal leak? I look for pooled threads that live too long and inspect the heap dump for values retained by ThreadLocalMap. The fix is to remove the value in a finally block or use a framework that cleans up after the request.
• How do you identify an off-heap leak? I compare heap usage with process RSS and native memory tracking output. If the heap stays flat but RSS keeps growing, the leak may be in direct buffers, native libraries, or metaspace.
• Does a heap dump always show the root cause? Usually for heap leaks, yes, because it reveals the retaining chain. For native memory or class metadata issues, you need extra tooling beyond the heap dump.
• Is System.gc() a valid test? Only as a rough demo, not as proof. It may reduce noise, but it cannot collect objects that are still strongly referenced.
• Does WeakReference prevent leaks? No. It can help caches release entries under memory pressure, but it is not a free fix for bad ownership or unbounded growth.

Tricky / gotchas:

• Can a leak exist even if heap looks stable? Yes. The leak may be native memory or metaspace, so the Java heap alone can look fine while the process RSS keeps rising.
• Is every growing collection a leak? No. A bounded cache, buffer pool, or startup index can grow intentionally and then plateau. The key question is whether growth is expected and capped.
• Does more heap always fix the problem? No. A bigger heap can hide the leak for longer, but it does not remove the retained references that caused it.

Common Mistakes:

• Watching only one snapshot. Fix: look at the trend over time, especially after full GC, not a single memory number.
• Confusing high allocation rate with a leak. Fix: a leak stays retained; allocation pressure usually comes and goes with traffic.
• Using heap size as the only signal. Fix: also inspect GC pause time, old generation growth, RSS, and native memory when needed.
• Scaling the heap instead of fixing ownership. Fix: find the retaining reference and remove or bound it.

Memory Hook: Think: ‘If it is still tied to a string, the GC cannot carry it away.’ The object can be thrown out only when nothing important is still holding it.

Cheat Sheet:

• Leak = unwanted retained reference, not just high memory.
• Best signal = heap keeps rising after full GC.
• Use -Xlog:gc* on Java 9+, legacy GC flags on Java 8.
• Take a heap dump and inspect retained size and GC roots.
• Common causes: static caches, ThreadLocal, listeners, queues, classloader leaks.
• If heap is fine but RSS grows, check off-heap and native memory.

Practice Tasks:

• Run the demo in leaky mode and observe how used heap behaves after forced GC.
• Modify the code so the cache is bounded to 5 entries, then compare the memory trend.
• Take a heap dump from a small sample app and find the biggest retained object chain in MAT.