Heap Dump Analysis: Detecting Memory Leaks with MAT, VisualVM, and YourKit

Heap dumps capture a snapshot of everything in your JVM memory at a specific moment. They are the definitive source for understanding memory issues—memory leaks, excessive allocation, classloader problems, and unexpected object retention. Without heap dump analysis, you are guessing about memory problems. With it, you have concrete evidence.

This guide covers three essential tools for heap dump analysis. Eclipse Memory Analyzer Tool (MAT) is free, powerful, and the first tool to reach for. VisualVM comes with the JDK and handles quick checks well. YourKit is commercial but offers superior usability and advanced features.

Introduction

Heap dumps capture a frozen moment of everything in your JVM’s memory—all live objects, their references, classloaders, and the full application state at the moment of capture. They are the definitive source of truth when diagnosing memory issues that allocation profilers cannot explain, when OutOfMemoryError occurs without a clear cause, or when memory usage grows over time and you need to find what is holding references that should have been released. Without heap dump analysis, you are guessing about memory problems. With it, you have concrete evidence.

Three tools dominate heap dump analysis: Eclipse Memory Analyzer Tool (MAT), VisualVM, and YourKit. MAT is free, powerful, and the first tool to reach for when investigating production incidents. It uses dominator trees and leak suspect reports to identify which objects retain the most memory and why they cannot be collected. VisualVM comes with the JDK and handles quick checks without additional installation. YourKit is commercial but excels at allocation site analysis—showing you not just what objects exist but where they were created. Each tool answers different questions about the same memory state.

This guide covers how to capture heap dumps reliably (including when the JVM is under extreme memory pressure), how to use each tool effectively, and how to trace retention chains all the way to GC roots. Failure scenarios show how static caches, classloader leaks, and connection pool exhaustion show up in dumps, and what patterns to look for when the obvious suspect turns out to be a symptom rather than the root cause.

When to Use Heap Dump Analysis / When Not to Use

Heap dumps are indispensable when you need to understand why memory is not being released, when OutOfMemoryError occurs, when memory usage grows over time without explanation, and when you need to find what is holding references to objects that should be garbage collected.

Avoid heap dumps when the JVM is at extreme memory pressure—taking a dump can cause an OutOfMemoryError or hung process. For performance issues that are not memory-related, heap dumps waste time. And if you need real-time allocation monitoring, use async-profiler allocation profiling instead.

Capturing heap dumps in production requires careful planning. The dump operation is stop-the-world for most JVM configurations, though modern JVMs with -XX:+HeapDumpOnOutOfMemoryError capture dumps without additional overhead when the error occurs.

Heap Dump Architecture

graph TD
    subgraph "JVM Heap"
        subgraph "Object Instances"
            O1[MyService<br/>1 instance<br/>256MB retained]
            O2[Cache<br/>1 instance<br/>128MB retained]
            O3[Connection Pool<br/>1 instance<br/>64MB retained]
        end
        subgraph "Reference Chains"
            O1 --> O2
            O2 --> O3
        end
    end

    subgraph "Heap Dump Tools"
        MAT[Eclipse MAT<br/>Dominator Tree<br/>Leak Suspects]
        VV[VisualVM<br/>Heap Summary<br/>OQL Queries]
        YK[YourKit<br/>Allocation Sites<br/>Retained Sets]
    end

    O1 -->|"Analyze"| MAT
    O2 -->|"Analyze"| VV
    O3 -->|"Analyze"| YK

Each tool approaches heap dump analysis differently. MAT focuses on finding memory waste through dominator trees and leak suspect reports. VisualVM provides a quick overview and supports object query language for custom analysis. YourKit emphasizes navigation—you can trace from any object to its GC roots with a click.

## Capturing Heap Dumps

### Using jmap

```bash
# Capture heap dump (requires JDK, not JRE)
jmap -dump:format=b,file=heapdump.hprof <pid>

# Dump only live objects (triggers GC first)
jmap -dump:live,format=b,file=heapdump-live.hprof <pid>

# Non-interactive dump with -F flag (if process is hung)
jmap -F -dump:format=b,file=heapdump.hprof <pid>

Automatic Dump on OutOfMemoryError

# JVM flags for automatic heap dump
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/var/log/heapdump.hprof \
     -Xmx2g -jar your-application.jar

Add a rollover policy to keep only recent dumps:

# Keep only last 10 dumps, each max 1GB
-XX:HeapDumpPath=/var/log/heapdump.hprof \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:NumberOfHeapDumpFiles=10 \
-XX:HeapDumpSize=1G

Using Diagnostic Commands

# Via jcmd (Java 9+)
jcmd <pid> GC.heap_dump filename=heapdump.hprof

# With live objects only
jcmd <pid> GC.heap_dump filename=heapdump.hprof live=true

Eclipse Memory Analyzer (MAT)

MAT is the most powerful free tool for heap dump analysis. The Dominator Tree view shows which objects retain the most memory and identifies why they cannot be collected.

Key Views

Leak Suspect Report automatically analyzes the dump and identifies likely memory problems. Start here for any new heap dump. The report explains which objects contribute most to memory retention and why they cannot be collected.

Dominator Tree shows the object retention hierarchy. An object A dominates object B if every path from a GC root to B passes through A. This tells you exactly which “owner” keeps other objects alive.

Histogram shows the count and shallow heap of objects by class. Sort by retained heap to find the biggest consumers.

MAT Analysis Workflow

# Open heap dump in MAT
# File -> Open Heap Dump -> select heapdump.hprof

# Run leak suspect report
# Right-click on heap dump in Heap Dump History -> "Leak Suspect Report"

In the leak suspect report, look for sections marked in red—they indicate problems. The “Shortest Paths to GC Roots” show why objects cannot be collected. The “Accumulated Objects” section shows which classes accumulate excessively.

VisualVM

VisualVM comes with the JDK and provides quick heap analysis without installing additional tools. It is less powerful than MAT but handles basic analysis quickly.

Key Features

Heapwalker provides the main heap analysis interface. The “Summary” tab shows overall heap statistics. The “Classes” tab shows object counts and sizes by class. The “Instances” tab shows actual objects and their fields. Right-click any instance to see “Paths to GC Roots.”

OQL Console supports Object Query Language for custom searches. Useful for finding specific patterns, like objects with particular field values or collections of unusual size.

Example OQL Queries

-- Find all ArrayList instances larger than 1000 elements
select a from java.util.ArrayList a where a.size > 1000

-- Find String instances containing specific text
select s from java.lang.String s where s.toString().indexOf("suspicious") >= 0

-- Find objects with retention over 10MB
select x from instanceof java.lang.Object x
where sizeof(x) > 10485760

YourKit

YourKit is a commercial profiler with the best usability for heap analysis. Its strength is navigation—you can click through object relationships intuitively.

Key Capabilities

Allocation recording captures where objects were created, not just that they exist. When analyzing heap dumps, the allocation site is shown alongside each object. This dramatically accelerates leak diagnosis because you know exactly which code path created leaking objects.

Retained set view shows exactly what a specific object keeps alive. Unlike MAT’s dominator tree, YourKit shows the full set of objects that would be collected if a specific object were collected.

Compare heap dumps takes two dumps and shows what changed. Objects that grew in count indicate potential leaks. This is invaluable for confirming whether memory issues are resolved.

Production Failure Scenarios

Scenario 1: Static Cache Growing Unboundedly

An application cache stores data forever instead of evicting old entries. The heap dump shows ConcurrentHashMap or similar collection retaining millions of entries. The dominator tree shows the cache itself as the top retainer.

The solution is implementing eviction policies—LinkedHashMap with access-order eviction, WeakHashMap for reference-based eviction, or dedicated cache libraries like Caffeine that handle eviction automatically.

Scenario 2: Classloader Memory Leak

After redeploying a web application, the old version’s classes remain in memory because something still references the old classloader. The heap dump shows classes from the old application still loaded.

This typically happens when static collections hold references to objects that should have been cleaned up. ThreadLocal values, static caches, and JMX MBeans are common culprits.

Scenario 3: Connection Pool Leak

Database connection pools that do not return connections properly accumulate connections over time. The heap dump shows physical database connections held by connection pool proxies that the application never closed.

The “Paths to GC Roots” trace reveals where the leaked connections are held—typically in some business logic object that acquired the connection but failed to return it.

Trade-off Table

Tool	Cost	Strength	Best For
Eclipse MAT	Free	Deep analysis, leak suspects	Production incident analysis
VisualVM	Free with JDK	Quick checks, OQL	Development debugging
YourKit	Commercial	Usability, allocation sites	Active development profiling

Implementation Snippets

Analyzing Heap Dump Programmatically with MAT API

import org.eclipse.mat.*;
import org.eclipse.mat.query.*;
import org.eclipse.mat.snapshot.*;
import org.eclipse.mat.util.*;

public class HeapDumpAnalyzer {

    public static void main(String[] args) throws Exception {
        // Open heap dump
        Snapshot snapshot = SnapshotFactory.openSnapshot(
            "heapdump.hprof",
            null);

        // Get dominator tree
        DominatorTree dominatorTree = snapshot.getDominatorTree();

        // Find largest retained objects
        ResultTable<?> result = dominatorTree.query(
            "SELECT retainedSize, shallowSize, this, className "
            + "ORDER BY retainedSize DESC LIMIT 20");

        for (Object row : result.getRows()) {
            System.out.printf("Retained: %s, Shallow: %s, Class: %s%n",
                formatSize(((Number) ((List<?>) row).get(0)).longValue()),
                formatSize(((Number) ((List<?>) row).get(1)).longValue()),
                row);
        }

        snapshot.dispose();
    }

    private static String formatSize(long bytes) {
        if (bytes < 1024) return bytes + "B";
        if (bytes < 1024 * 1024) return String.format("%.1fKB", bytes / 1024.0);
        if (bytes < 1024 * 1024 * 1024) {
            return String.format("%.1fMB", bytes / (1024.0 * 1024));
        }
        return String.format("%.1fGB", bytes / (1024.0 * 1024 * 1024));
    }
}

Quick Analysis with jhat

# jhat is deprecated but still useful for quick analysis
jhat -J-Xmx2g heapdump.hprof

# Then open http://localhost:7000 in browser
# Use OQL console for queries:
# select x from com.mycompany.MyClass x where x.field != null

Observability Checklist

Before concluding heap analysis is complete, verify these points. The heap dump captured the problematic state—dumps taken too early may not show the leak. The dump included live objects only—dumps with all objects obscure actual retention. You traced retention paths all the way to GC roots, not just to intermediate holders. The root cause is in application code, not a framework or library that you cannot change.

Also confirm that multiple dumps show consistent patterns, that the objects you identified as leaks correlate with the time when memory usage grew, and that your fix actually addresses the root cause rather than symptoms.

Security and Compliance Notes

Heap dumps contain everything in JVM memory at capture time. This includes user data, session information, passwords in memory, and application internals. Treat heap dumps as sensitive data.

For regulated environments, heap dumps may fall under data handling requirements. Identify whether dumps contain PII, financial data, or other regulated information before analysis. Analyze dumps in secure environments. Do not transfer dumps over untrusted networks.

Consider automating heap dumps with strict access controls rather than allowing ad-hoc captures. Log all heap dump operations for audit purposes.

Common Pitfalls / Anti-Patterns

The biggest mistake is analyzing dumps from the wrong time. A dump taken during normal operation looks nothing like one taken during OutOfMemoryError. Always capture dumps at the moment of failure or when memory pressure is highest.

Another issue is confusing retained size with shallow size. Shallow size is the object itself. Retained size includes all objects that would be collected if the object were collected. Always look at retained size when diagnosing memory issues.

Not following references all the way to GC roots leads to fixing symptoms. An object might be held by another object, which is held by a third—keep tracing until you find the GC root.

Finally, forgetting that some leaks are in permanent generation or metaspace (classloaders, interned strings) before Java 8. These require different analysis approaches than heap dumps of Java heap.

Quick Recap Checklist

• Capture heap dumps with -XX:+HeapDumpOnOutOfMemoryError in production
• Use MAT for deep analysis and leak suspect reports
• Use VisualVM for quick checks and OQL queries
• Use YourKit for allocation site analysis and intuitive navigation
• Always trace retention paths to GC roots
• Distinguish retained size from shallow size
• Protect heap dumps—they contain sensitive application data

Interview Questions

Further Reading

• Eclipse Memory Analyzer Tool (MAT) — Official MAT website with downloads and documentation
• VisualVM — Official VisualVM project page included with JDK
• YourKit Java Profiler — Commercial profiler with heap analysis capabilities
• IBM Pattern Modeling and Analysis Tool for Java Garbage Collector — PMAT for analyzing IBM JVM GC logs
• JDK Troubleshooting Guide - Heap Profiling — Oracle documentation on heap analysis techniques

Conclusion

Heap dump analysis is the definitive method for diagnosing memory leaks and understanding object retention. Use -XX:+HeapDumpOnOutOfMemoryError in production to capture dumps automatically at failure. Eclipse MAT provides the most powerful free analysis with leak suspect reports and dominator tree views. VisualVM handles quick checks, and YourKit excels at allocation site analysis.

The key to effective heap analysis is capturing dumps at the right moment (during memory pressure) and tracing retention paths all the way to GC roots. Always distinguish retained size from shallow size, and protect heap dumps as sensitive data containing your application’s full memory state.