skip to content

Name the JDK's live JVM monitoring and profiling tools and say what each is best at: jstat, VisualVM, Java Flight Recorder, and async-profiler.

level: middleimportance: should knowfreq 50%

answer

  1. jstat = CLI GC/heap counters, near-zero overhead, quick glance
  2. VisualVM = GUI all-rounder, graphs + dump browsing, dev/staging
  3. JFR = built-in event recorder, ~1% overhead, production, view in JMC
  4. async-profiler = flame graphs, no safepoint bias, CPU/alloc hot paths
  5. Live tools for trends; heap dump + MAT for object-level

basics

~20 s

jstat prints live GC and memory stats from the command line. VisualVM is a GUI that shows memory, threads, and lets you take dumps. Java Flight Recorder records detailed events with very low overhead for later analysis. async-profiler is a low-overhead sampling profiler great for CPU and allocation flame graphs.

solid answer

~50 s

These are complementary live tools, used while the app runs rather than on a post-mortem dump. jstat is a lightweight CLI that polls a running JVM and prints GC counts, pause times, and per-generation heap occupancy — good for a quick 'is GC thrashing?' check over SSH. VisualVM is a free GUI that attaches to a JVM to graph heap/CPU/threads, browse a heap dump, and do basic sampling — the convenient all-rounder. Java Flight Recorder (JFR) is the built-in, always-on-capable event recorder: it captures GC, allocation, lock contention, I/O, and method-sampling events into a .jfr file at very low (~1%) overhead, analyzed in JDK Mission Control — ideal for production. async-profiler is a sampling profiler that uses OS perf counters and avoids the safepoint bias of older profilers; it produces CPU, allocation, and lock flame graphs cheaply, making it the go-to for finding hot code paths. Rough rule: jstat for a glance, JFR/async-profiler for deep low-overhead profiling, VisualVM/MAT for dump analysis.

go deeper

for a junior

Can name a couple of tools (VisualVM, jstat) and say one shows GUI graphs and one prints GC stats.

for a middle

Matches each tool to its job: jstat for a quick GC check, VisualVM for graphs/dumps, JFR for low-overhead recording, async-profiler for flame graphs.

for a senior

Picks the right tool per environment (JFR in prod, async-profiler for hot paths), knows JFR is free since 11, and explains overhead trade-offs and safepoint bias.

for a principal

Standardizes the org's observability stack (e.g. always-on JFR with retention, flame-graph workflows), integrates JFR/profiler output into incident response, and balances overhead, coverage, and data-retention policy.

## Two families of memory tooling There are two situations. **Post-mortem analysis** uses a static **heap dump** to see object-level detail after a problem (covered by jmap + Eclipse MAT). **Live monitoring/profiling** watches a *running* JVM to see trends and behavior over time. This question is about the live family. The tools below all ship with or work against a normal JDK. ## jstat — the lightweight CLI gauge `jstat` (JVM statistics monitoring tool) polls a running JVM and prints numbers to the console. For example: ``` jstat -gcutil <pid> 1000 ``` prints, every 1000 ms, the percentage occupancy of each heap region (Eden/Survivor/Old/Metaspace), the number of young and full GCs, and total GC time. It is text-only, near-zero overhead, and needs nothing installed beyond the JDK — perfect for a quick check on a remote server: *Is the old generation filling up? Are full GCs frequent and long?* It does **not** tell you *which objects* or *which code* — just aggregate counters. ## VisualVM — the GUI all-rounder **VisualVM** is a free graphical tool (formerly bundled with the JDK, now a separate download). It attaches to a local or remote JVM and shows live graphs of heap usage, CPU, thread states, and loaded classes. It can **capture and browse heap dumps** (a lighter alternative to MAT for smaller dumps), take thread dumps, and do basic **sampling** of CPU and memory. Its strength is convenience and a gentle learning curve; its weakness is that its instrumenting profiler adds noticeable overhead, so it is more a development/staging tool than a production one. ## Java Flight Recorder (JFR) — low-overhead event recording **Java Flight Recorder** is a profiling and event-collection framework **built into the JVM** (free and open since JDK 11). Instead of sampling on demand, JFR continuously emits structured **events** — GC cycles, object allocations, lock contention, exceptions, file/socket I/O, and periodic method-execution samples — into a compact `.jfr` file. Its defining feature is **very low overhead** (commonly cited around 1%), low enough to leave running in **production**. You start a recording with a flag or `jcmd`: ``` jcmd <pid> JFR.start name=rec settings=profile duration=120s filename=rec.jfr ``` You then open the `.jfr` file in **JDK Mission Control (JMC)**, a GUI that visualizes the events: allocation hot spots, GC behavior, longest locks, and more. JFR is the tool you reach for when you need rich diagnostics from a live production system without slowing it down. ## async-profiler — low-overhead sampling & flame graphs **async-profiler** is a popular open-source (non-JDK) sampling profiler. Older Java profilers could only sample threads at **safepoints** (points where the JVM can safely pause a thread), which biases results toward methods near safepoints (*safepoint bias*). async-profiler instead uses OS-level performance counters (e.g. Linux `perf_events`) and async signals to sample stacks anywhere, giving accurate **CPU**, **allocation**, **lock**, and **wall-clock** profiles at low overhead. Its signature output is the **flame graph**: a stacked visualization where the width of each box is the time/allocations attributed to that call path, so the widest towers are your hot spots. It is the community favorite for pinpointing why a service is CPU-bound or allocation-heavy. ## How they fit together - **Quick triage on a server:** `jstat` — is GC the problem at all? - **CPU/allocation hot-path hunting:** async-profiler flame graphs, or JFR's allocation profiling. - **Always-on production diagnostics:** JFR (low overhead, structured events) → analyze in JMC. - **Convenient dev/staging GUI and small dumps:** VisualVM. - **Deep leak/object analysis on a dump:** Eclipse MAT (the post-mortem companion). No single tool does everything: you triage with the cheap ones, then escalate to the detailed ones, and switch to a heap dump when you need to see individual objects and reference chains.

  • Why is JFR safe to run in production while VisualVM's profiler usually isn't?
    JFR records pre-defined events through hooks the JVM already has, at roughly 1% overhead, so it barely perturbs the app. VisualVM's instrumenting profiler can rewrite bytecode to add timing around methods, which slows the app significantly and distorts the very timings it measures.
  • What is safepoint bias and why does async-profiler avoid it?
    Many profilers can only capture a thread's stack at a safepoint (a JVM-chosen pause point), so samples cluster near safepoints and misattribute time to the wrong methods. async-profiler samples via OS perf counters/async signals, capturing stacks anywhere, so the profile reflects where time is actually spent.

saying these in an interview costs you the question

  • Claiming VisualVM's instrumenting profiler is fine for production — its overhead is high; JFR/async-profiler are the low-overhead choices.
  • Thinking JFR needs a commercial license — it has been free and open since JDK 11.
  • Confusing jstat (aggregate counters) with a profiler that shows hot methods or specific objects.
  • Believing older safepoint-based profilers give unbiased results; async-profiler exists precisely to avoid safepoint bias.

context

resolving links…