skip to content

What exactly does GET /actuator/heapdump produce, and what operational cautions apply when triggering it?

level: seniorimportance: should knowfreq 42%

answer

  1. HeapDumpWebEndpoint → HotSpotDiagnosticMXBean.dumpHeap
  2. binary HPROF .hprof, octet-stream attachment
  3. live=true → full GC first, reachable only
  4. stop-the-world pause ~ heap size
  5. contains secrets → highly sensitive; open in MAT

basics

~20 s

It generates and downloads a binary HPROF (.hprof) heap dump of the live JVM heap via the HotSpotDiagnosticMXBean. It's large (roughly heap size), pauses the app while dumping, and contains all in-memory data including secrets.

solid answer

~50 s

GET /actuator/heapdump is handled by HeapDumpWebEndpoint, which calls the platform HotSpotDiagnosticMXBean.dumpHeap() to write a binary HPROF file and streams it back as a downloadable attachment (application/octet-stream). By default it's a live dump — a full GC runs first and only reachable objects are captured. Operational cautions: (1) it's a stop-the-world pause proportional to heap size, so on a big heap it can freeze request processing for seconds; (2) the file is roughly the size of the used heap — hundreds of MB to GB — so watch disk/temp space and bandwidth; (3) it contains every object's contents, so passwords, tokens, session data and PII are all in there — treat it as highly sensitive and never expose the endpoint publicly. You analyze it in Eclipse MAT, VisualVM or JProfiler to find leak suspects and dominators.

go deeper

for a junior

Know it downloads a binary heap-dump file used to debug memory.

for a middle

Know the .hprof format and that you analyze it in MAT/VisualVM.

for a senior

Explain the live-dump/full-GC semantics, stop-the-world cost, size, and secret-leak risk.

for a principal

Reason about safe production capture (replica/drained node, HeapDumpOnOutOfMemoryError) and the security boundary for the endpoint.

**What it is.** `HeapDumpWebEndpoint` exposes the JVM's heap-dump capability over HTTP. On GET it locates a `HeapDumper` — on HotSpot/OpenJDK JVMs this delegates to `com.sun.management.HotSpotDiagnosticMXBean.dumpHeap(filename, live)`. The result is an **HPROF** file (the standard binary heap-dump format, conventionally `.hprof`), written to a temporary file and then streamed to the client as a downloadable attachment with content type `application/octet-stream` and a `Content-Disposition` header. Spring deletes the temp file after the response completes. **Live dump semantics.** The `live` flag defaults to true, meaning the JVM first performs a **full garbage collection** and then dumps only objects still reachable (live). This makes the dump smaller and more meaningful for leak analysis (garbage isn't included), but the GC itself is a cost. **HPROF contents.** The dump is a complete snapshot of the heap: every object instance, its fields, array contents, class metadata, and — critically — the **actual bytes of Strings and byte arrays**. That means anything in memory at that instant is captured: database passwords, JWT/OAuth tokens, HTTP session contents, cached PII, encryption keys held in memory. There is no redaction. **Operational cautions.** 1. **Pause / latency.** Producing the dump is a **stop-the-world** operation whose duration scales with live-set size. On a multi-GB heap this can be several seconds of frozen application — enough to blow request timeouts and health checks. Never casually trigger it on a hot production node under load. 2. **Size & I/O.** The file is roughly the size of the used heap (often hundreds of MB to several GB). It's written to the temp directory first, so you need free disk there, and then transferred over the network. Repeated calls can fill disk. 3. **Security.** Because it externalizes raw memory, the endpoint is one of the most dangerous to expose. Lock it behind Spring Security / a private management port / cluster-internal network only; treat any downloaded dump as a secret artifact and delete it after analysis. 4. **Availability.** On non-HotSpot JVMs or restricted environments the underlying MXBean may be unavailable, in which case the endpoint can't produce a dump. **Analysis workflow.** Open the `.hprof` in **Eclipse Memory Analyzer (MAT)** (Leak Suspects report, Dominator Tree, Histogram), **VisualVM**, **JProfiler**, or `jhat`/`jmap` tooling. You look for the dominator objects retaining the most memory, unexpected large collections, duplicated Strings, or classloader leaks. **When to use.** Diagnosing OutOfMemoryError / suspected leaks / abnormal heap growth. For routine monitoring prefer JVM metrics (Micrometer `jvm.memory.*`, GC metrics) and only capture a heap dump when you need object-level detail. In production, prefer taking the dump from a drained/replica instance, or set `-XX:+HeapDumpOnOutOfMemoryError` so the JVM writes one automatically at the moment of OOM rather than pulling it live under load.

  • Why can triggering a heap dump on a busy production node be dangerous beyond just security?
    It's a stop-the-world pause proportional to heap size (plus a full GC for a live dump), so it can freeze request handling for seconds, trip timeouts/health checks, and the multi-GB file consumes temp disk and bandwidth.
  • What tool would you use to analyze the resulting file and what would you look for?
    Eclipse MAT (or VisualVM/JProfiler). Look at the Leak Suspects report and Dominator Tree for objects retaining the most heap, oversized collections, duplicate Strings, or classloader leaks.
  • How could you capture a heap dump at the moment of an OutOfMemoryError instead of pulling one live?
    Run the JVM with -XX:+HeapDumpOnOutOfMemoryError (and -XX:HeapDumpPath=...); the JVM writes an .hprof automatically when OOM occurs, avoiding a manual live dump under load.

saying these in an interview costs you the question

  • Saying heapdump returns JSON or readable text
  • Claiming it's cheap/instant with no pause
  • Ignoring that the dump contains secrets/PII
  • Thinking the default dump includes garbage (it's a live dump after full GC)

context

resolving links…