skip to content

Explain the flags in `jmap -dump:live,format=b,file=heap.hprof <pid>`. What does each part do, and why does 'live' matter?

level: middleimportance: should knowfreq 48%

answer

  1. live = reachable-only AND runs a full GC first
  2. format=b = binary HPROF (the only real choice)
  3. file= = path on the TARGET host
  4. live → cleaner/smaller dump, longer pause
  5. jcmd GC.heap_dump -all=false ≈ live

basics

~20 s

It dumps the heap to a file. live includes only reachable objects (and runs a garbage collection first), format=b writes the standard binary .hprof format, and file=heap.hprof is the output path. 'live' matters because it filters out short-lived garbage so a leak stands out.

solid answer

~50 s

`jmap -dump:<options>` writes a heap snapshot. The comma-separated options: `live` tells the JVM to include only objects still reachable from GC roots — and crucially it triggers a full garbage collection *before* dumping, so unreferenced garbage is swept out and what remains is what is genuinely held. `format=b` selects the binary HPROF format (the only practical choice; analyzers like Eclipse MAT and VisualVM read it). `file=heap.hprof` is the destination path on the target host's filesystem. The `live` flag matters because without it the dump contains a mix of truly-retained objects and not-yet-collected garbage, making leaks harder to spot and inflating the file. The tradeoff: `live` forces a stop-the-world GC plus the dump pause, so on a large heap it pauses the application longer. If you need to see *all* objects (including unreachable ones the GC hasn't reaped) you omit `live`.

go deeper

for a junior

Knows the command writes a heap dump and can point at file= as the output path.

for a middle

Explains each option (live/format=b/file=), and that live both filters to reachable objects and runs a GC first.

for a senior

Articulates the pause/cleanliness tradeoff of live, disk-sizing, where the file lands for remote/container JVMs, and the jcmd equivalent.

for a principal

Decides dump policy under SLOs: when to accept the pause for a cleaner dump vs capture-all, automated -XX:+HeapDumpOnOutOfMemoryError, and offline-analysis pipelines.

## Anatomy of the command `jmap -dump:live,format=b,file=heap.hprof <pid>` asks a **running JVM** (identified by `<pid>`, its OS process id) to write a **heap dump** — a complete snapshot of the objects in its **heap** (the memory where Java objects live). The `-dump:` prefix is followed by a comma-separated list of options. Let's define each. ### `live` **Reachable / live** means an object can still be reached by following references from a **GC root** (a starting point the garbage collector treats as always-alive: running thread stacks, static fields, JNI references). The **garbage collector (GC)** is the JVM subsystem that automatically frees objects that are *not* reachable. The `live` option does two things: (1) it asks the JVM to run a **full GC** first, then (2) it includes only the objects that survived — the reachable ones. Why run a GC first? Because at any instant the heap also contains **garbage**: objects that are already unreachable but that the GC simply hasn't gotten around to freeing yet. If you dump *without* `live`, those dead objects appear in the snapshot too. For leak hunting you want to know what is *genuinely retained*, so `live` removes the noise and shrinks the file. The cost: a full GC is a **stop-the-world** event — application threads are paused while it runs — and the dump itself also pauses the app (see safepoints below). On a multi-gigabyte heap this can be a multi-second pause. So `live` trades a longer pause for a cleaner, smaller dump. When would you *omit* `live`? When you suspect the problem is unreachable objects piling up (e.g., a finalizer backlog) and you want to see everything before a GC sweeps it, or when you must avoid triggering a GC that could mask the state you are investigating. ### `format=b` `format=b` means **binary**, producing the standard **HPROF binary format** (conventionally a `.hprof` file). This is the format that heap analyzers — **Eclipse MAT (Memory Analyzer Tool)** and **VisualVM** — read. There is effectively no useful alternative for real analysis; historical text formats are gone. Treat `format=b` as boilerplate you always include. ### `file=heap.hprof` The output path, written on the **filesystem of the host running the target JVM** (not your laptop, if you are remote). Make sure there is enough free disk: a dump is roughly the size of the live heap, so a 4 GB heap yields a ~4 GB file. Use an absolute path to be sure where it lands. ## Putting it together - With `live`: GC first, then snapshot only reachable objects → smaller, cleaner, better for leak analysis, but a longer pause. - Without `live`: snapshot everything currently in the heap (reachable + not-yet-collected) → bigger, noisier, no extra GC. ## Modern equivalent `jcmd <pid> GC.heap_dump -all=false /path/heap.hprof` is the recommended modern form; `-all=false` corresponds to `live` (dump only live objects after a GC), `-all=true` corresponds to omitting `live`.

  • Roughly how big will the .hprof file be?
    Approximately the size of the live heap — a 4 GB heap produces a ~4 GB dump, so ensure enough free disk on the target host.
  • What is the modern jcmd equivalent of the live flag?
    `jcmd <pid> GC.heap_dump -all=false <file>` — `-all=false` dumps only live objects after a GC (like `live`); `-all=true` dumps everything (like omitting `live`).

saying these in an interview costs you the question

  • Thinking 'live' just filters output — it also triggers a full stop-the-world GC, which has a real pause cost
  • Assuming the file lands on your local machine when attaching to a remote/containerized JVM — it is written on the target host
  • Treating format=b as optional or expecting a human-readable file — it is binary and must be opened in an analyzer

context

resolving links…