Your JVM has a black box. Are you actually using it? ✈️☕
🔸 TLDR
JFR is an event-based recording framework built into the JDK.
It continuously captures JVM and application telemetry with very low overhead, allowing you to investigate CPU usage, GC pauses, memory leaks, threading, I/O, exceptions and much more.
And its most interesting target is not your laptop.
It is production. 🚀
🔸TRUTH
What if your JVM could keep a black box running continuously: ready to tell you what happened before your application started misbehaving? ✈️
That is the idea behind JDK Flight Recorder (JFR).
At JavaOne 2026, Mikael Vidstedt from Oracle demonstrated why JFR is much more than a profiler you launch when development gets slow.
🔸 "USE IT IN PRODUCTION"
Vidstedt repeated this message throughout the session.
The default JFR configuration is designed for less than 1% overhead.
That changes the troubleshooting model:
▪️ Keep JFR running continuously
▪️ Let it maintain historical JVM telemetry
▪️ Dump the recording when something goes wrong
▪️ Analyze what happened before the incident
Instead of trying to reproduce a mysterious production problem afterward, you already have evidence.
🔸 "IT'S A TIME MACHINE" ⏪
One of my favorite descriptions from the talk:
"It's a time machine that allows you to go back and see what led up to that."
That historical context is incredibly powerful.
A slow request happened?
You can correlate it with:
▪️ GC pauses
▪️ CPU saturation
▪️ Thread activity
▪️ Socket/File I/O
▪️ JIT compilation
▪️ Exceptions
▪️ Lock contention
Correlation is often where troubleshooting becomes diagnosis.
🔸 MUCH MORE THAN CPU PROFILING
The demos showed several real troubleshooting workflows.
🔥 High CPU? Use JFR views to identify hot methods.
⏱️ Latency spikes? Inspect GC pauses and JVM configuration.
🧠 Suspected memory leak? Use old-object sampling and paths to GC roots to trace unexpectedly retained objects.
💥 Application not responding? Aggregate exceptions by type and message to expose failures such as a missing database driver.
🔸 BUILT INTO THE JVM
JFR can capture events about:
▪️ Garbage collection
▪️ JIT compilation
▪️ Class loading
▪️ Threads and synchronization
▪️ Network and file I/O
▪️ TLS handshakes and certificates
▪️ Exceptions
▪️ Custom application events
You can control it with -XX:StartFlightRecording, attach to a running JVM with jcmd, analyze recordings with the jfr CLI or JDK Mission Control, and even consume events programmatically through streaming APIs.
🔸 TAKEAWAYS
▪️ JFR is not merely a development profiler.
▪️ Its low overhead makes continuous production recording practical.
▪️ Historical telemetry can be more valuable than reproducing an incident later.
▪️ Built-in JVM events + custom business events make correlation extremely powerful.
▪️ Start with the default configuration, then increase detail when the investigation requires it.
Your JVM already knows an incredible amount about what it is doing.
JFR gives you a practical way to ask it what happened. 🔎☕
#Java #JDK #JFR #JDKFlightRecorder #JavaOne #JVM #Performance #Observability #JavaPerformance #Troubleshooting #OpenJDK
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaFullstackBook👇