Java Flight Recorder 实战：用 JFR 飞行记录仪定位性能问题

Java Flight Recorder（简称 JFR）是 OpenJDK 从 11 起免费内置的事件记录框架，能以低于 1% 的采样开销，持续收集 JVM 的 CPU、内存、GC、锁、IO 与线程等运行时数据。它像飞机上的”黑匣子”，把生产环境最难复现的性能问题原样录下来，让你在事后用 JMC 慢慢回放、精准定位，而不是靠猜。

一、JFR 是什么，为什么开销这么低

传统 APM 或采样型 Profiler 往往在每次方法进入/退出都插桩，开销随调用量线性增长；而 JFR 采用事件驱动 + 环形缓冲的设计。JVM 内部在关键路径上埋了上千个事件点（如 GC 开始/结束、线程阻塞、对象分配、文件读写、套接字收发），事件仅以极小的二进制结构写入进程内的一块固定大小内存，满了就覆盖最旧的。因为是 C++ 层面直接写入内存，不经过 Java 堆，也不加锁，所以常驻录制的开销可以压到 1% 以内。

录制产物是一个扩展名为 .jfr 的二进制文件，基于 XML 定义的事件 schema，可被 Java Mission Control（JMC）可视化，也能用官方 jfr 命令行工具或 jdk.jfr 的流式 API 程序化解析。这正是它比 thread dump、heap dump 更适合”持续观测”的原因——前者是某一瞬间的快照，JFR 是一段时间的连续录像。

二、三种启动录制的方式

2.1 启动参数：跟随 JVM 一起开

适合需要”从启动那一刻起就录”的场景，比如复现一个启动慢的问题。下面这段参数会在应用启动后延迟 20 秒、录制 60 秒、以 profile 模板写入文件：

java -XX:+FlightRecorder      -XX:StartFlightRecording=delay=20s,duration=60s,filename=recording.jfr,settings=profile      -jar myapp.jar

settings=profile 是比默认 default 更细的模板，会开启方法采样、对象分配、锁竞争等更重的事件；default 则只保留开销极低的基础事件，可 7×24 常驻。

2.2 jcmd：运行时动态开关（最常用）

生产环境最推荐的方式：先不录，等问题出现再动态开启，录完即停。先拿到 Java 进程 PID：

jps -l
# 输出类似：12345 com.example.MyApp

# 开启一个 60 秒的录制，存到 /tmp/recording.jfr
jcmd 12345 JFR.start name=myrecording duration=60s filename=/tmp/recording.jfr settings=profile

# 中途也可以手动 dump 当前缓冲（无需等 duration 结束）
jcmd 12345 JFR.dump name=myrecording filename=/tmp/recording_now.jfr

# 停止并落盘
jcmd 12345 JFR.stop name=myrecording

# 查看正在进行的录制
jcmd 12345 JFR.check

2.3 代码内 API：把录制嵌进业务

当你想”在接口超时瞬间自动存一段录像”时，可以用 jdk.jfr 的 API 在代码里精确控制。下面在捕获异常时 dump 最近 120 秒的环形缓冲：

import jdk.jfr.Configuration;
import jdk.jfr.FlightRecorder;
import jdk.jfr.Recording;

public class JfrGuard {
    private static final Recording rec = new Recording(
        Configuration.getConfiguration("profile"));

    static {
        rec.setMaxAge(java.time.Duration.ofSeconds(120)); // 环形缓冲只留 120s
        rec.start();
    }

    public static void dumpOnIncident(String tag) {
        try {
            rec.dump(java.nio.file.Path.of("/tmp/incident-" + tag + ".jfr"));
        } catch (Exception e) {
            // 录制失败不应影响主流程
        }
    }
}

三、常用事件类型与配置模板

JFR 的事件有几百种，但日常定位性能问题，下面这几类最关键。profile 模板默认会开启大部分：

四、jcmd 实战：采集一次生产慢请求

假设监控告警说接口 P99 从 200ms 飙到 2s。先在告警触发时立刻开录，时长覆盖问题窗口：

# 开一个 120 秒的录制
jcmd 12345 JFR.start name=slowapi duration=120s filename=/tmp/slowapi.jfr settings=profile

# 等窗口过去后，确认文件已生成
ls -lh /tmp/slowapi.jfr

# 把文件拉到本地，用 JMC 打开分析
scp server:/tmp/slowapi.jfr ./slowapi.jfr

把 .jfr 拖进 JMC（Oracle 或 Eclipse 版均可，需装 Flight Recorder 插件）后，重点看三个视图：Method Profiling 的火焰图看 CPU 热点，GC 页看停顿分布，Lock Instances 看被阻塞最久的锁。

五、程序化解析 .jfr：把录像变成告警

不想每次人工开 JMC？JDK 11+ 提供了 jfr 命令行和流式 API，可以把录像直接喂给自动化分析。下面用 jfr 工具做摘要统计：

# 打印录像中的事件类型与数量
jfr summary slowapi.jfr

# 筛选 GC 停顿超过 200ms 的事件
jfr print --events "jdk.GCPhasePause" --max-size 5M slowapi.jfr

# 用 jdk.jfr 流式 API 在 Java 里消费事件
jfr stream slowapi.jfr {
    if (event instanceof jdk.GCPhasePause pause && pause.duration > 200_000_000) {
        System.out.println("长停顿: " + pause.duration / 1_000_000 + " ms, phase=" + pause.name);
    }
}

把这段逻辑放进定时任务，就能对历史录像做”长 GC 停顿 TOP N””锁等待超阈值”等自动巡检，比单纯看 Grafana 折线更下钻。

六、实战案例：三类典型瓶颈怎么看

结合前面提到的内链，JFR 的定位结论常常要和 JVM 调优、虚拟线程等知识交叉印证：

# 常驻一个 180s 环形缓冲（不写文件，纯内存）
jcmd 12345 JFR.start name=continuous maxage=180s settings=default

# 告警时立即 dump 最近 180s
jcmd 12345 JFR.dump name=continuous filename=/tmp/incident.jfr