JVM tool guide · memory

Eclipse MAT: Find Memory Leaks in Java Heap Dumps

Eclipse Memory Analyzer (MAT) is the standard tool for analyzing Java heap dumps. Its headline artifacts are two reports — the Leak Suspects overview and the Dominator Tree — that together tell you which objects suck up memory and what is anchoring them to the GC roots.

You feed it a .hprof dump (from jmap -dump:live or jcmd GC.heap_dump) and its size-of and dominator calculations quickly separate 'huge legitimate cache' from 'objects that should have been freed'. OQL lets you write queries when the reports aren't enough.

Official Eclipse MAT project

Use it when

• You have an OutOfMemoryError or a steadily-growing Old-gen and need to find the culprit.

• You want to quantify what individual class instances actually cost (shallow vs retained size).

• You want to see the path from a GC root to a big object ('why is this still reachable').

Skip it when

• You need a live-heap histogram only — jmap -histo or jcmd snippets are faster.

• Your problem is GC *behavior* rather than a stale object graph — GC log analysis is the tool.

Capture a dump and open it

MAT consumes standard .hprof dumps. Capture with jmap or jcmd, launch MAT, and File > Open Heap Dump.

jcmd <pid> GC.heap_dump /tmp/heap.hprof
# or
jmap -dump:live,file=/tmp/heap.hprof <pid>

Leak Suspects report

MAT's Overview runs an automated Leak Suspects analysis listing the top 'suspects' — big accumulations with their GC-root path. Start here on any dump.

Dominator Tree vs Histogram

Histogram (class-by-class counts/sizes) is a first scan. The Dominator Tree shows retained-size dominance — which objects, if freed, would free the most memory. Switch between them with the toolbar.

Path to GC Roots

For any object, right-click to see the path from a GC root. This answers 'why is this still alive' — classic causes are static collections, ThreadLocal, listener registries, and Caches with long TTLs.

OQL for custom queries

OQL (Object Query Language) is SQL-like. SELECT * FROM instanceof java.lang.String, or filter instances of your own classes.

SELECT * FROM java.util.ArrayList
SELECT sum(o.@retainedHeapSize) FROM instanceof com.example.CacheEntry o
Quick start

Get productive in minutes

From dump to suspect in 3 clicks

Open the dump and read the automated overview.

# 1) capture
jcmd <pid> GC.heap_dump /tmp/heap.hprof
# 2) open in MAT
# 3) Overview > Leak Suspects

Frequently asked questions

Shallow vs retained size?

Shallow size is the object's own footprint (header + fields). Retained size is what would be freed if this object (and its exclusively-reachable children) were collected. Retained size is what leaks analysis cares about.

Dump too big / parsing timeout?

MAT can run out of heap parsing huge dumps itself. Increase MAT's -Xmx (e.g., edit MemoryAnalyzer.ini to -Xmx8g) and prefer -dump:live (smaller) dumps for leak searches.

MAT vs VisualVM heap dump?

VisualVM opens dumps for quick instance browsing; MAT is purpose-built for leak/dominance analysis with retained sizes. Use MAT for real forensics.

Last updated August 2026 · JVM Tools is independent and not affiliated with Oracle.