How do you detect a memory leak?

A Java memory leak happens when objects that are no longer needed remain reachable through some reference chain, so the garbage collector cannot reclaim them. The classic signature is heap usage that trends upward over time, Full GCs that run more and more frequently yet free less and less memory, and eventually an OutOfMemoryError. You detect it by watching the sawtooth GC pattern drift upward, capturing a heap dump (automatically with -XX:+HeapDumpOnOutOfMemoryError), and analyzing the dump in a tool like Eclipse MAT or VisualVM to find which objects dominate the heap and what is keeping them alive.

What does a memory leak look like?

Healthy heap usage looks like a sawtooth: it rises as objects are allocated, then drops sharply after each GC as garbage is reclaimed, staying within a stable band. A leak breaks this pattern. The low points of the sawtooth creep steadily upward over hours or days because each GC leaves behind more objects than the last, since those objects are still reachable. This upward drift of the post-GC baseline is the single clearest sign of a leak.

  Healthy (sawtooth stays flat):     Leak (baseline drifts upward):
  ╱╲  ╱╲  ╱╲  ╱╲  ╱╲  ╱╲          ╱╲  ╱╲   ╱╲    ╱╲     ╱╲
 ╱  ╲╱  ╲╱  ╲╱  ╲╱  ╲╱  ╲        ╱  ╲╱  ╲ ╱  ╲  ╱  ╲   ╱  ╲
 ────────────────────────          ╱    ╲╱   ╲╱    ╲╱    ╲ ╱    OOM!
  post-GC baseline is flat          post-GC baseline climbs

What happens as the leak progresses?

As the leak grows, the Old Generation fills with live-but-useless objects. The JVM responds by running Full GCs more and more often, trying to reclaim space, but because the objects are still referenced, each Full GC frees almost nothing. You see Full GCs clustering together, the application pausing frequently, and GC time rising as a percentage of uptime. Finally the heap cannot satisfy an allocation and the JVM throws OutOfMemoryError: Java heap space.

How do you capture a heap dump?

To diagnose, enable -XX:+HeapDumpOnOutOfMemoryError so that when the OOM happens the JVM automatically writes a .hprof snapshot. You can also trigger a dump on demand.

# Automatic dump on OOM (set at JVM startup)
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/dumps/bank-api.hprof \
     -Xmx4g -jar bank-api.jar

# Manual dump from a running process
jmap -dump:live,format=b,file=/tmp/heap.hprof <pid>

# Modern alternative
jcmd <pid> GC.heap_dump /tmp/heap.hprof

How do you analyze the dump?

Open the dump in Eclipse Memory Analyzer (MAT). MAT's Dominator Tree shows which objects retain the most memory, and its "Leak Suspects" report often points straight at the culprit. The key concept is the retention chain: MAT shows the "path to GC roots," the chain of references keeping an object alive, which tells you exactly what to fix.

What are common leak patterns in banking code?

package com.bank.service;

import java.util.HashMap;
import java.util.Map;

public class AuditCache {
    // LEAK: static map that only grows – nothing ever removes entries
    private static final Map<String, String> auditLog = new HashMap<>();

    public void recordAudit(String txnId, String detail) {
        auditLog.put(txnId, detail);  // grows without bound!
    }
}

// FIX: use a bounded cache with eviction
// Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(Duration.ofHours(1)).build();

• Other common leak causes:
• Listeners or callbacks registered but never unregistered. Each registration adds an object to a list that grows forever.
• ThreadLocal values not removed in a thread pool. The pool reuses threads, so the ThreadLocal value persists across requests.
• Unclosed resources (streams, connections) that hold native memory or buffer references.

How do you catch leaks before an OOM?

A senior engineer does not wait for a crash. You trend heap usage after GC on a monitoring dashboard and alert when the post-GC baseline climbs steadily over time.

# Watch post-GC heap usage with jstat
jstat -gcutil <pid> 5000
# Look at the O (Old Gen usage %) column – if it climbs to 90%+ and stays, investigate

In banking applications at National Bank of India, Rajesh sets an alert when the post-GC Old Gen usage exceeds 80% for more than 10 minutes, giving the team time to capture a heap dump and investigate before the service crashes.