How do you use jcmd to control Java Flight Recorder (JFR) on a running JVM, and why is JFR often preferred over ad-hoc heap/thread dumps for performance investigations?

## What JFR is **Java Flight Recorder (JFR)** is a profiling and event-collection engine *built into the JVM itself* (open-sourced from JDK 11; the engine exists in current OpenJDK builds). Instead of taking a single snapshot, JFR continuously emits thousands of small **events** — method-sampling for CPU, object allocations, monitor (lock) contention, GC pauses, thread parks, file/socket I/O, exceptions, and JVM-internal metrics — into an in-memory ring buffer that is periodically flushed to a `.jfr` file. Its whole design goal is **very low overhead** (commonly ~1-2% with the default/profile settings), so it can run on production. ## Driving JFR with jcmd jcmd is the way to control JFR on a JVM that is *already running* (you didn't pre-configure recording at launch): ``` # Start a 2-minute recording using the richer 'profile' template jcmd <pid> JFR.start name=diag settings=profile duration=120s filename=/tmp/diag.jfr # See what recordings exist and their state/size jcmd <pid> JFR.check # Snapshot the data captured so far WITHOUT stopping jcmd <pid> JFR.dump name=diag filename=/tmp/diag-partial.jfr # Stop the recording and flush the final file jcmd <pid> JFR.stop name=diag filename=/tmp/diag-final.jfr ``` Key arguments: - **settings** — a template: `default` (low overhead, ~1%) or `profile` (more detail, more overhead). You can supply a custom `.jfc`. - **duration** — auto-stop after a time window; omit it for an open-ended recording you stop manually. - **maxsize / maxage** — cap the on-disk/ring size so a long recording doesn't grow unbounded (oldest data is dropped). - **name** — a label so you can target dump/stop/check at a specific recording. You can also start JFR at launch (`-XX:StartFlightRecording=...`) or run it always-on as a continuous ring you `JFR.dump` from when an incident occurs. ## Analyzing the file Open the `.jfr` in **JDK Mission Control (JMC)** (or process it with `jfr print`). You get: **CPU flame graphs / hot methods** (where wall/CPU time goes), **allocation profiles** (which call sites allocate the most — the leak/GC-pressure source), **lock contention** (which monitors block which threads), **GC pause timelines**, and **I/O and exception** views. ## Why JFR beats ad-hoc dumps 1. **Continuous vs. instantaneous.** A thread dump is one frozen instant; a heap dump is one memory snapshot. JFR records *over a window*, so you see the *distribution* of where time and allocations actually go — far better for "the app is slow/CPU-heavy" questions where the cause is statistical, not a single stuck thread. 2. **Low, bounded overhead.** Sampling at ~1-2% means you can leave it on in production; a giant heap dump pauses the app and writes gigabytes. 3. **Correlated, multi-dimensional.** One recording ties together CPU, allocation, locks, GC, and I/O on a common timeline, so you can see *why* a latency spike happened (e.g. a GC pause coinciding with an allocation storm), not just one facet. 4. **No restart, command-driven.** jcmd starts/stops it on a live JVM — ideal during an incident. ## When you still want the dumps JFR is the default for *performance* (where does time/allocation go?). You still take a **heap dump** when you need the full object-reference graph to chase a *retention/leak* path, and a **thread dump** for a quick, human-readable view of a *deadlock or hang*. The mature practice: JFR running continuously, with on-demand thread/heap dumps via jcmd for the specific forensic question.