Java Profiling in Production — async-profiler and JFR
Fast recall
Quick revision
Core answer
Awareness of production-safe profiling tools vs dev-only tools
Enabling JVMTI-based profilers in production — they add significant overhead and affect measurements
Explain safepoint bias in JVMTI profilers (they only sample at safepoints, missing native and I/O wait) and why async-profiler avoids this
Interview-ready guide
Interview answer
Java profilers fall into two categories with fundamentally different accuracy characteristics: JVMTI-based profilers that can only sample at safepoints, and async-profiler which samples at arbitrary execution points. The distinction matters because safepoint-biased sampling can make hot code invisible in flame graphs.
Why standard profilers mislead:
- YourKit and JProfiler use JVMTI safepoint sampling — 10-30% overhead and can only capture stack traces at safepoints
- Code running between safepoints (native calls, tight loops, kernel I/O) is invisible — the profile looks complete but systematically misrepresents hot paths
async-profiler:
- Uses Linux
perf_events+AsyncGetCallTrace— captures traces regardless of safepoints - Near-zero overhead — safe in production; generates flame graphs for visual hot-path identification
Java Flight Recorder (JFR):
- Built into the JVM since Java 11 — 1-2% overhead; records GC events, class loading, thread activity, exceptions
- Always-on in production:
-XX:+FlightRecorder -XX:StartFlightRecording=filename=recording.jfr,dumponexit=true
Recommended approach:
- Flame graphs from async-profiler first — identify CPU hot spots
- JFR for GC, thread, and lock contention data
- Never optimize based on JVMTI profiler output that may be missing safepoint-invisible regions
I recommend async-profiler as the first tool for CPU profiling and JFR for JVM event analysis — both are production-safe.
Java Profiling in Production — async-profiler and JFR
Direct Answer
Use async-profiler for CPU and memory profiling with minimal overhead (1-3%). Java Flight Recorder (JFR) is built into the JVM and captures CPU, GC, threads, and I/O in production. Avoid traditional profilers (YourKit, JProfiler) in production — they add 10-30% overhead.
Deep Dive & Architecture
Java Flight Recorder (JFR) is a low-overhead event recorder built directly into the HotSpot JVM.
It captures GC events, CPU samples, thread states, lock contention, allocation patterns, JIT compilation, class loading, and I/O — all in a single recording with under 1% overhead.
Open-sourced in Java 11, JFR is designed to run continuously in production. Start it via -XX:StartFlightRecording=... at JVM launch or on-demand with jcmd <pid> JFR.start. Analyze the resulting .jfr file in JVM Mission Control (JMC) for correlated timeline views, or query the events programmatically via the jdk.jfr.consumer API. JFR is the right tool for after-the-fact diagnosis — when monitoring shows a latency spike, JFR tells you what was happening inside the JVM at that moment.
A common mistake is using JMH micro-benchmarks or YourKit in production to investigate latency, then drawing wrong conclusions because the instrumentation itself caused the slowdown
Common Mistakes & Pitfalls
Enabling JVMTI-based profilers in production — they add significant overhead and affect measurements
Check your understanding
Answer these without looking back at the article.
- How do you take and analyze a Java thread dump? How do you identify deadlocks?
- What is Java Flight Recorder? How do you capture and analyze JFR recordings, and when is it the right tool?
- How do you profile a Java application? Explain the difference between sampling and instrumenting profilers and when to use each.
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.