Java Flight Recorder (JFR) is essential for diagnosing production Java issues with minimal overhead. 1. JFR captures critical runtime data including CPU profiling, garbage collection, thread activity, exceptions, I/O, and JVM internals, enabling analysis of latency spikes, memory leaks, deadlocks, and performance degradation. 2. Enable JFR at startup using -XX: FlightRecorder and -XX:StartFlightRecording with options for duration, delay, and settings, or attach dynamically to running JVMs via jcmd JFR.start for on-demand diagnostics. 3. Analyze .jfr files using JDK Mission Control (JMC) for visual insights into hot methods, GC trends, and thread behavior, or use command-line tools like jfr for automated processing. 4. Best practices include enabling JFR by default, using rolling recordings, securing output files, integrating with APM tools, avoiding prolonged profile settings unless needed, and testing on resource-constrained systems. Proactively using JFR ensures issues are captured and analyzed without reproduction, transforming troubleshooting into efficient root-cause discovery.

Java Flight Recorder (JFR) is a powerful diagnostic and profiling tool built into the JDK, especially useful for troubleshooting performance issues in production environments. It collects detailed runtime data with minimal overhead—typically less than 2%—making it safe to use even in live systems.

Here’s how JFR can be effectively used for production troubleshooting:

1. What JFR Captures (and Why It Matters)

JFR records a wide range of low-level and application-level events, including:

• CPU profiling (method-level execution times, hot methods)
• Garbage collection (GC duration, frequency, heap usage, pause times)
• Thread activity (lock contention, blocked threads, thread states)
• Class loading/unloading
• Exception telemetry (frequency of exceptions thrown)
• I/O and network activity (if enabled)
• JVM internal operations (safepoints, code cache, compiler activity)

This data is invaluable when diagnosing:

• Sudden latency spikes
• Memory leaks or high GC pressure
• Deadlocks or thread bottlenecks
• Unexpected application slowdowns

Because JFR runs continuously in the background (when enabled), you can capture a recording after an issue occurs—retroactively analyzing what happened.

2. Enabling JFR in Production

JFR is available in OpenJDK 11 and all Oracle JDKs (with fewer restrictions in commercial versions). To use it in production:

Start your JVM with JFR enabled:

java -XX: FlightRecorder \
     -XX:StartFlightRecording=duration=60s,filename=diagnosis.jfr \
     -jar myapp.jar

Or, for continuous monitoring:

java -XX: FlightRecorder \
     -XX:StartFlightRecording=delay=30s,duration=0s,filename=rolling.jfr,settings=profile \
     -jar myapp.jar

Note: Use settings=profile for more detailed event profiling (e.g., object allocation, method profiling). The default settings=default is lighter.

For already-running JVMs (attach dynamically):

Use jcmd to start a recording without restarting:

jcmd <pid> JFR.start name=web-issue duration=120s filename=/tmp/issue.jfr settings=profile

Later, stop it:

jcmd <pid> JFR.stop name=web-issue

This is ideal when an issue arises unexpectedly.

3. Analyzing JFR Recordings

Once you have a .jfr file, analyze it using:

JDK Mission Control (JMC)

• Open-source GUI tool designed specifically for JFR analysis.
• Visualize flame graphs, GC trends, thread timelines, and I/O patterns.
• Filter events, inspect stack traces, and identify hot methods.

Alternative: Use command-line or CI tools

• Tools like jfr or JFR-Analyzer allow automated parsing.
• Extract metrics programmatically for integration into monitoring pipelines.

Example: Finding a CPU spike

1. Open the JFR file in JMC.
2. Go to the “Hot Methods” view.
3. Look for methods consuming high CPU (self time or total time).
4. Check the stack trace to locate the root cause—e.g., inefficient loop, regex backtracking, or serialization bottleneck.

4. Best Practices for Production Use

• ? Enable JFR by default on production JVMs (low overhead, high value).
• ? Use continuous rolling recordings (e.g., 1-hour buffers) to capture recent history.
• ? Secure .jfr files—recordings may contain sensitive data (e.g., method parameters, stack traces).
• ? Combine with APM tools (like Datadog, New Relic) for correlation.
• ? Avoid long-duration recordings with settings=profile unless necessary—higher overhead.
• ? Don’t enable JFR on very resource-constrained systems without testing.

Bottom Line

JFR is one of the most effective tools for diagnosing production Java issues with minimal impact. When enabled proactively, it turns reactive firefighting into proactive root-cause analysis. You don’t need to reproduce the problem in staging—JFR likely already captured it.

Set it up once, and it pays dividends every time something goes wrong.

Basically: If you’re not using JFR in production, you’re flying blind.

The above is the detailed content of Java Flight Recorder (JFR) for Production Troubleshooting. For more information, please follow other related articles on the PHP Chinese website!