What is a memory leak in Java

In Java, a Memory Leak is not the physical loss of allocated memory addresses (as in C or C++), but unintentional object retention: objects that are logically obsolete and no lo...

🟢 Junior Level

In Java, a Memory Leak is not the physical loss of allocated memory addresses (as in C or C++), but unintentional object retention: objects that are logically obsolete and no longer needed by application logic remain strongly reachable from a GC Root, preventing the Garbage Collector from ever reclaiming their memory.

Real-World Analogy

Imagine a corporate office storage locker:

When an employee finishes a client project, company policy states that project folders should be shredded.
However, someone left sticky notes with “Active Reference” tags on the old project archive boxes.
The custodial team (Garbage Collector) is strictly forbidden from discarding any box with an active tag.
As new projects arrive, more tagged boxes accumulate until the storage room (JVM Heap) fills completely, bringing all office work to a grinding halt.

Java vs. C/C++ Memory Leaks

Dimension	C / C++ Memory Leak	Java Memory Leak
Underlying Mechanism	A pointer to allocated heap memory is destroyed or lost without first invoking `free()` or `delete`.	The pointer is never lost; an active reference chain from a GC Root continues to hold the object.
Accessibility	The memory block is unreachable by application code and cannot be freed without restarting the process.	The object is fully accessible in memory, but business logic never accesses it again.
GC Role	Low-level OS memory allocator cannot detect unreferenced blocks.	The Garbage Collector operates correctly: it preserves the object because it observes an active GC Root path.

Common Symptoms of a Java Memory Leak

Steady Memory Growth: Heap consumption gradually increases over hours, days, or weeks of runtime.
GC Thrashing: The Garbage Collector runs continuously, consuming 90–99% of CPU time trying to reclaim memory, while only freeing tiny slivers of heap space.
Latency Spikes: Application response times degrade from milliseconds to tens of seconds due to frequent Stop-The-World pauses.
Fatal Crash: The JVM inevitably crashes with java.lang.OutOfMemoryError: Java heap space.

   [ Active GC Root (e.g., Static List) ]
                    │
                    ▼ (Accidental Strong Reference)
   [ Obsolete Object (e.g., 50 MB Cache Entry) ] ──> Cannot be collected!

🟡 Middle Level

The Three Leak Domains in JVM Architecture

Memory leaks in Java can strike across three fundamentally distinct memory regions:

┌────────────────────────────────────────────────────────────────────────┐
│                        JVM PROCESS MEMORY                              │
├──────────────────────────┬───────────────────────┬─────────────────────┤
│      1. Java Heap        │     2. Metaspace      │    3. Off-Heap      │
│  - Static collections    │  - ClassLoader leaks  │  - DirectByteBuffer │
│  - Unbounded caches      │  - Dynamic proxies    │  - JNI / C libraries│
│  - ThreadLocal retention │  - Framework bytecode │  - Netty ByteBufs   │
└──────────────────────────┴───────────────────────┴─────────────────────┘

On-Heap Leaks: Business objects retained by static fields, unbounded collections, or unremoved listeners (java.lang.OutOfMemoryError: Java heap space).
Metaspace Leaks: Class metadata retained because custom ClassLoaders fail to unload during dynamic hot-reloading (java.lang.OutOfMemoryError: Metaspace).
Off-Heap / Native Leaks: Direct native memory allocated via ByteBuffer.allocateDirect() or JNI libraries that are never released back to the operating system.

Telemetry Patterns: Healthy Sawtooth vs. Leaking Baseline Creep

Monitoring heap metrics in APM tools (Prometheus, Grafana, Datadog) reveals distinct signatures:

Healthy JVM Heap (Stable Sawtooth):
Heap MB |   /\    /\    /\    /\    /\
        |  /  \  /  \  /  \  /  \  /  \
        | /    \/    \/    \/    \/    \  ──> Stable Post-GC Baseline Floor (~200 MB)
        └──────────────────────────────── Time

Leaking JVM Heap (Baseline Creep):
Heap MB |               /\    /\   [ OOM Crash! ]
        |         /\   /  \  /  \      ▲
        |   /\   /  \ /    \/    \     │
        |  /  \ /    \                 │
        | /    \ ──────────────────────┴─ Rising Post-GC Baseline Floor (Creeping Upward)
        └──────────────────────────────── Time

Healthy Baseline: Following each Major/Full GC, heap occupancy drops back down to a constant floor (the working set).
Leaking Baseline: Following each GC cycle, the post-collection floor rises continuously. Even though Minor GCs run, the reclaimed volume shrinks until the heap is packed with uncollectible garbage.

🔴 Senior Level

`ThreadLocal` Leaks in Pooled Thread Environments

One of the most insidious memory leaks in enterprise Java applications occurs when using ThreadLocal in container environments (Tomcat, Jetty, Netty, or ThreadPoolExecutor):

public class SecurityContextHolder {
    private static final ThreadLocal<UserSession> CONTEXT = new ThreadLocal<>();

    public static void set(UserSession session) { CONTEXT.set(session); }
    public static UserSession get() { return CONTEXT.get(); }
    public static void clear() { CONTEXT.remove(); }
}

The Internal Leak Mechanics:

Every java.lang.Thread instance holds an internal package-private map: ThreadLocal.ThreadLocalMap.
In this map, the Key is a WeakReference<ThreadLocal<?>>, but the Value is a Strong Reference to the payload object (UserSession).
In web application servers, worker threads do not terminate after finishing an HTTP request; they return to a thread pool to be reused for subsequent requests.
If code fails to invoke CONTEXT.remove():
- Even if the ThreadLocal instance itself is garbage collected (clearing the weak key to null), the entry’s Value remains strongly reachable from the running worker thread!
- The thread pins the UserSession, which pins domain models, which pins the web application’s ClassLoader, leaking gigabytes of heap and metaspace.
- Security Data Leak: The next unrelated HTTP request dispatched to this pooled thread will inherit the previous user’s credentials!

The Robust Production Pattern:

try {
    SecurityContextHolder.set(currentSession);
    filterChain.doFilter(request, response);
} finally {
    SecurityContextHolder.clear(); // MANDATORY: Guarantees eviction even on exceptions!
}

Heap Dump Analysis via Eclipse MAT: Dominator Tree

When analyzing an .hprof heap dump using Eclipse Memory Analyzer Tool (MAT):

┌────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐
│                     Shallow Heap                       │                     Retained Heap                      │
├────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤
│ • Memory consumed directly by the object ITSELF        │ • Total memory that would be FREED if this object were │
│   (Object header + primitive fields + reference slots) │   garbage collected.                                   │
│ • e.g., A `HashMap` instance shallow size = 48 bytes   │ • e.g., That same `HashMap` retaining 3.2 GB data!     │
└────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘

The Dominator Tree:

An object $A$ is said to dominate object $B$ if every reference path from any GC Root to $B$ must traverse $A$.

In Eclipse MAT, open the Dominator Tree sorted by Retained Heap.
Right-click the top retaining object $\to$ select Path to GC Roots $\to$ Exclude all phantom/weak/soft references.
This isolates the exact chain of strong references preventing the object from being reclaimed.

Linux OOM Killer in Docker / Kubernetes (Exit Code 137)

In containerized cloud environments, Java applications frequently terminate abruptly with Exit Code 137 (Linux SIGKILL) without producing an OutOfMemoryError or .hprof heap dump.

The Cause: Container RSS Memory Breach

The Linux kernel cgroup controller enforces strict memory limits based on Resident Set Size (RSS)—the entire physical memory consumed by the process:

\[\text{Total Container Memory (RSS)} = \text{Heap (-Xmx)} + \text{Metaspace} + (N_{\text{threads}} \times \text{-Xss}) + \text{CodeCache} + \text{DirectMemory} + \text{GC Native Metadata}\]

Container RAM Limit: 4.0 GB
┌───────────────────────────────────────────────────────────────────────────┐
│ Heap (-Xmx3g): 3.0 GB                                                     │
├────────────────────────────────┬─────────────────────┬────────────────────┤
│ Metaspace: 400 MB              │ 1,000 Threads (1 GB)│ Direct Buffers: 0.5│
└────────────────────────────────┴─────────────────────┴────────────────────┘
Total Physical Footprint: 4.9 GB  ──>  EXCEEDS 4.0 GB CGROUP CEILING!
──> Linux OOM Killer sends SIGKILL (137) immediately; JVM cannot write dump!

Production Diagnostic Fix:

Always size container limits with a 25–30% buffer over -Xmx.
Enable Native Memory Tracking to inspect non-heap allocations:
```
-XX:NativeMemoryTracking=summary
```
Inspect in real time via: jcmd <pid> VM.native_memory baseline / detail.diff.

4 Tricky Questions

1. How does a memory leak in Java fundamentally differ from a memory leak in C or C++?

Answer: In C or C++, a memory leak occurs when the program allocates heap memory (via malloc or new) and subsequently loses all pointer references to that memory without first deallocating it (free or delete). The memory is physically orphaned and can never be reached or freed by the process. In Java, a memory leak occurs when an object is no longer needed by business logic, but an active reference path from a GC Root continues to point to it. The Garbage Collector cannot reclaim the object because, from the JVM’s perspective, the object is still strongly reachable and legally in use.

2. Why does using `ThreadLocal` in a web application or thread pool frequently cause both memory leaks and security data leaks?

Answer: In thread pools, worker threads are never terminated; they are indefinitely recycled to handle subsequent incoming requests. A thread stores its ThreadLocal values in an internal ThreadLocalMap. While the map keys are weak references, the map values are strong references. If a thread does not explicitly execute ThreadLocal.remove() in a finally block before finishing a request, the value object remains strongly referenced by the living worker thread indefinitely. This causes a memory leak (retaining user objects and class loaders) and a security vulnerability (subsequent requests processed by the same worker thread will read the prior user’s security context).

3. Why is “Retained Size” rather than “Shallow Size” the critical metric when analyzing an Eclipse MAT heap dump for memory leaks?

Answer: Shallow Size measures only the physical memory consumed directly by the object itself (its object header, primitive instance fields, and pointer handles), which is almost always tiny—typically 16 to 64 bytes. For example, a ConcurrentHashMap instance has a shallow size of around 64 bytes. In contrast, Retained Size measures the total amount of memory that would be reclaimed if that specific object were garbage collected; it includes the object’s shallow size plus the memory of all other objects exclusively reachable through it (its dominator subtree). A 64-byte map holding millions of records might have a retained size of several gigabytes, pinpointing it as the true memory leak culprit.

4. Why does a Java container in Kubernetes get terminated with Exit Code 137 without generating a heap dump, even when `-Xmx` is set well below the container limit?

Answer: Exit Code 137 indicates that the Linux kernel terminated the process with SIGKILL via the kernel OOM Killer because the container exceeded its cgroup memory limit. The -Xmx parameter caps only the Java Heap. The operating system tracks the total Resident Set Size (RSS), which includes thread stacks (-Xss $\times$ thread count), Metaspace, JIT CodeCache, Direct ByteBuffers (off-heap memory), and JVM internal GC metadata. If these off-heap areas push total memory beyond the cgroup ceiling, the kernel kills the JVM instantly from the outside. Because the JVM is killed abruptly at the OS level, it never receives an internal OutOfMemoryError and cannot execute -XX:+HeapDumpOnOutOfMemoryError.

🎯 Interview Cheat Sheet

30-Second Elevator Pitch

“A Java Memory Leak is unintentional object retention: logically dead objects remain strongly reachable from a GC Root, preventing the Garbage Collector from freeing them. While healthy systems show a flat post-GC baseline in their sawtooth memory graph, leaking applications exhibit continuous baseline creep. Leaks occur across three domains: Heap (unbounded static collections, unremoved ThreadLocal values in pooled threads), Metaspace (ClassLoader retention), and Off-Heap (unreleased DirectByteBuffer native buffers). In production, memory leaks are diagnosed by capturing heap dumps via -XX:+HeapDumpOnOutOfMemoryError and evaluating Retained Size in the Dominator Tree of Eclipse MAT.”

Key Architectural Takeaways

Core Definition: Obsolete objects held hostage by active GC Root reference chains.
Java vs C++: In C++, pointer is lost; in Java, reference is retained unintentionally.
The Sawtooth Graph: Healthy heaps maintain a stable post-GC baseline; leaking heaps show upward baseline creep and GC thrashing.
ThreadLocal Hazard: Always invoke .remove() inside a finally block in pooled thread environments to prevent memory and security leaks.
Shallow vs Retained: Always prioritize Retained Heap in Eclipse MAT’s Dominator Tree to locate the root memory accumulator.
Exit Code 137 in Kubernetes: Caused by Linux cgroup OOM Killer when total RSS (Heap + Metaspace + Stacks + Direct Memory) exceeds the pod limit.

Red Flags & Anti-Patterns

🚩 Claiming “Java cannot have memory leaks because it has Garbage Collection”: Fundamental misunderstanding of reachability analysis.
🚩 Attempting to solve memory leaks by increasing -Xmx: Merely delays the crash and prolongs Stop-The-World pause durations.
🚩 Using ThreadLocal without remove() in a finally block: Retains data and ClassLoaders in thread pools indefinitely.
🚩 Sorting memory profiling results by Shallow Size: Completely obscures large collections retaining gigabytes of data.
🚩 Confusing a Java Heap OOM with a Linux Cgroup OOM Killer (Exit Code 137): Fails to account for native off-heap memory, thread stacks, and Metaspace.

When does an object become eligible for GC — Root reachability and reference lifecycles
How can a memory leak occur in Java — Concrete leak patterns and code anti-patterns
What is Metaspace (or PermGen) — ClassLoader leaks and metadata bloat
What is a heap dump — HPROF memory snapshot capture and structure
What are GC roots — Root reference taxonomy and reachability trees