Thread dump vs heap dump: which one do you actually need?

Both files get generated in the same bad moments — an outage, an OutOfMemoryError, a JVM that stopped answering — and the names are close enough that people search for one while needing the other. The distinction is worth thirty seconds, because analyzing the wrong snapshot wastes an hour: a thread dump tells you what the JVM is doing; a heap dump tells you what the JVM is holding.

This guide covers what each snapshot contains, which symptom calls for which, how to capture both without hurting production, and which tool reads each one. One honest note up front: ThreadMine analyzes thread dumps — for heap dumps we will point you at the right tools instead of pretending.

Two snapshots, two questions

• Thread dump — "what is every thread doing right now?" A text snapshot of each live thread: its stack trace, its state (RUNNABLE, BLOCKED, WAITING…), and the locks it holds or waits for. Kilobytes in size, captured in milliseconds. The tool for hangs, deadlocks, CPU spikes and exhausted pools.
• Heap dump — "what is filling the memory?" A binary snapshot (usually a .hprof file) of every object in the heap: its class, its fields, and who references it. As large as the heap itself — often gigabytes. The tool for memory leaks and OutOfMemoryError: Java heap space.

The two are complementary, not rivals. A serious memory incident often uses both: the heap dump names the objects that filled the memory, and the thread dump shows which code paths were busy creating them when the music stopped.

What's inside a thread dump

One entry per thread, and each entry is a story: the thread's name, its state, the full stack of what it was executing, and the monitor/lock lines that connect it to other threads.

"http-nio-8080-exec-7" #41 daemon prio=5 tid=0x... nid=0x2f03 waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
	at com.example.Cache.get(Cache.java:42)
	- waiting to lock <0x000000076ab00000> (a com.example.Cache)
	at com.example.Api.handle(Api.java:88)

Because it is plain text and costs almost nothing to produce, the standard advice is to capture several dumps a few seconds apart and compare them — a thread stuck on the same lock across three snapshots is a finding; a thread seen waiting once is just a Tuesday. Reading those patterns at scale is exactly what an analyzer automates: our complete guide to thread dump analysis walks through the manual version.

What's inside a heap dump

Every object alive in the heap at that instant, with its actual field values and the full reference graph — who points at whom. That graph is what makes memory-leak analysis possible: a memory analyzer computes the dominator tree and can say "this one HashMap retains 3.2 GB", or that a stopped classloader is still pinned by a single listener. None of that information exists in a thread dump — stacks reference code, not object contents.

The price is physics: the file is roughly as large as the used heap, writing it pauses the JVM, and opening it needs a serious workstation. A heap dump is a scalpel — precise, and not something you swing casually at production every few seconds.

Which one for which symptom

The last row is the one that surprises people: an OutOfMemoryError does not automatically mean "heap dump". When the message is unable to create new native thread, memory is fine — the process ran out of threads, and a thread dump showing 4,000 workers named pool-7-thread-N is the whole diagnosis.

How to capture each one

Thread dump — any of these, against the JVM's pid:

jstack -l <pid> > dump.txt          # the classic
jcmd <pid> Thread.print > dump.txt   # the modern equivalent
kill -3 <pid>                        # no JDK tools? dump goes to stdout

Take at least three, a few seconds apart. Finding the pid, Windows, containers and Spring Boot Actuator are covered in how to take a thread dump.

Heap dump — same tools, different verbs:

jcmd <pid> GC.heap_dump /tmp/heap.hprof        # modern
jmap -dump:live,format=b,file=heap.hprof <pid>  # classic ("live" runs a full GC first)

# insurance — set BEFORE the incident:
java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps ...

That last flag is the cheapest observability you will ever configure: the JVM writes the heap dump at the exact moment of the OutOfMemoryError, when the evidence is still in the room.

Cost and safety in production

• Thread dump: take it freely. The safepoint pause is milliseconds, the file is small text, and repeated captures are not just safe — they are the recommended technique.
• Heap dump: plan for it. The JVM pauses while the entire heap is written to disk — seconds to minutes on large heaps — and the file needs as much free disk as the heap is big. On a struggling node, that pause is visible to users.
• They differ in sensitivity, too. A heap dump contains your actual data: strings, user records, tokens — whatever was in memory. Treat the file like a database extract. A thread dump exposes class names, stack traces and thread names — internal, but in a different league.

The right tool for each side

For heap dumps, the reference is Eclipse Memory Analyzer (MAT) — free, with a leak-suspects report and the dominator tree that does the retention math for you. VisualVM gives a lighter first look, and commercial profilers (JProfiler, YourKit) bundle the same analysis with their tooling. Hosted options exist as well (HeapHero, from the same family as fastThread). ThreadMine does not analyze heap dumps — if the file ends in .hprof, those are your tools.

For thread dumps, you can read the text by hand — every line of it — or hand the pattern-matching to a free online thread dump analyzer: paste the dump, no sign-up, and ThreadMine detects deadlocks, pool exhaustion, thread leaks and virtual-thread pinning automatically, grades the snapshot with a health score, and stitches multiple dumps into a timeline. Prefer reading by eye with a desktop tool? That works too — we compare ourselves honestly against IBM TMDA and jstack.review, including when they are all you need.

Whichever side of this page brought you here: capture the cheap snapshot first, keep the expensive one for memory-shaped symptoms, and let each file be read by the tool that was built for it.