Why Relying Only on top and jstack Is Outdated: Embracing JDK Flight Recorder for Modern Java Troubleshooting

1. Why Using Only jstack Often Misses the Real Problem

When a Spring Boot order service experiences a sudden CPU rise (e.g., from 35% to 95%) and P99 latency jumps from 300 ms to 4.8 s, engineers typically capture a stack trace with jstack 24581 > /tmp/jstack.log and look for the busiest thread. The stack shows methods like OrderService.queryOrder(), UserService.getUser(), HashMap.get(), ArrayList.forEach(), but it represents only a single point in time.

A JVM snapshot is akin to a photograph; many performance problems require a timeline. For example, the following timeline shows CPU increase at 10:20:01, massive object allocation at 10:20:08, GC rise at 10:20:15, thread contention at 10:20:22, and P99 breaking 4 s at 10:20:30. Capturing a jstack at 10:20:35 would miss all preceding events.

JFR records continuous events such as thread sampling, locks, and GC, enabling analysis of the entire incident window.

2. Recording 2 Minutes of JFR When CPU Spikes

Assuming the Java process PID is 24581, start a 2‑minute recording with:

jcmd 24581 JFR.start \
  name=incident \
  settings=profile \
  duration=120s \
  filename=/tmp/incident-%p-%t.jfr

name

gives the recording a label, settings=profile uses the richer profile configuration, duration=120s limits the recording to two minutes, and filename specifies the output file. This can be done on a running JVM without restarting Spring Boot, which is crucial because restarting would erase the fault context.

3. What You Can See After Obtaining a .jfr File

Run jfr summary /tmp/incident.jfr to get an overview. You can also filter and print specific categories, e.g.:

jfr print \
  --categories GC \
  --events CPULoad \
  /tmp/incident.jfr

Typical focus areas:

CPU : Which methods continuously consume CPU? Hot stacks? JSON serialization? Collection operations? Exception loops?

GC and Object Allocation : Who is allocating objects aggressively? Why does GC suddenly increase? Is the young generation filling quickly?

Threads : Are threads running or waiting? Is there lock contention? Are many threads blocked?

IO and Socket : For sudden interface slowdown, examine socket activity, file IO, and thread waits.

4. Ideal Scenarios for JFR

JFR shines when the system does not crash but performance degrades gradually: CPU never reaches 100 %, no OOM, occasional DB slowdown, GC not severe, yet P99 latency climbs. In such cases, a single metric looks harmless, but JFR reveals the underlying cause, such as a method that continuously consumes CPU after a business change that increased userIds from 20 to 10 000.

5. Continuous (“Loop”) Recording Like a Dashcam

Instead of starting JFR only after an incident, configure a continuous recording that retains only the most recent window:

jcmd 24581 JFR.start \
  name=continuous \
  settings=default \
  disk=true \
  maxage=30m \
  maxsize=512m

maxage=30m

keeps the last 30 minutes, maxsize=512m limits disk usage. When an alarm fires (e.g., at 10:35), dump the last 10 minutes:

jcmd 24581 JFR.dump \
  name=continuous \
  maxage=10m \
  filename=/tmp/incident-%t.jfr

This provides a pre‑incident timeline rather than a post‑incident snapshot.

6. JFR Is Not a Replacement for Prometheus or Logs

Having JFR does not mean you can discard monitoring, logging, or Arthas.

Typical division of labor:

Prometheus / Grafana → Detect "system is unhealthy"
Logs / Trace          → Answer "which request failed"
JFR                  → Answer "what happened inside the JVM"
Arthas / jstack      → Answer "what is happening right now"

Each tool complements the others.

7. Virtual Threads Increase the Need for Continuous Observation

With virtual threads, applications may have far more concurrent tasks than traditional platform threads, making full thread‑dump analysis impractical. Continuous sampling, aggregation, and timeline correlation—exactly what JFR provides—become essential.

8. Minimal Command Set for Spring Boot Production

List Java processes: jcmd -l Record a 2‑minute incident:

jcmd 24581 JFR.start name=incident settings=profile duration=120s filename=/tmp/incident.jfr

Check recording status: jcmd 24581 JFR.check Dump the last 10 minutes of a continuous recording:

jcmd 24581 JFR.dump name=continuous maxage=10m filename=/tmp/incident.jfr

Quick summary: jfr summary /tmp/incident.jfr These commands are part of the JDK, require no extra installation, and can be incorporated into an SOP that maps CPU spikes, memory growth, latency increase, and intermittent issues to the appropriate JFR view.

9. Final Thoughts

Oracle is highlighting JFR again, but the real shift needed is in troubleshooting habits. Modern Java services—Spring Boot, microservices, containers, virtual threads, complex GC, many external calls—cannot be fully understood with only top and jstack. Treat JFR as the JVM’s built‑in dashcam to capture what the JVM does before, during, and after an incident.