Java JFR 事件采样如何降低诊断开销

Java JFR（Java Flight Recorder）要降低诊断开销，重点不是把所有事件都关掉，而是把记录范围缩小到当前问题：持续观察优先使用 default.jfc，短时深挖再考虑 profile.jfc，周期采样用 period 拉开间隔，耗时事件用 threshold 过滤短调用，只有确实需要定位调用路径时才保留 stackTrace。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/jdk.jfr/

先把 JFR 记录范围收窄

把 JFR 当成线上常驻诊断工具时，先用默认配置建立基线。Oracle 对两套预置配置的定位很清楚：default.jfc 记录量较克制，适合持续记录；profile.jfc 包含更多事件，适合需要更多信息的短时剖析。不要为了“可能有用”直接长期启用 profile。

# 中文注释：先用低开销配置记录 60 秒，文件写到当前目录
jcmd  JFR.start name=baseline settings=default duration=60s filename=baseline.jfr

# 中文注释：只有复现窗口很短、需要更多事件时才临时使用 profile
jcmd  JFR.start name=deep settings=profile duration=30s filename=deep.jfr

如果问题只与 CPU 消耗有关，可以进一步只打开采样事件，不要把锁、文件、网络和类加载事件全部叠加。配置应在录制启动前完成，这样记录从一开始就使用目标设置。

用 period、threshold 和堆栈开关控制数据量

周期采样不是越密越好。需要观察趋势时可以把 jdk.CPUSample 的周期设为 2 秒；只有在短暂复现窗口内，才考虑更密的周期。对持续时间事件，threshold 可以过滤掉低于门槛的调用，减少“记录很多、判断很少”的噪声。堆栈则要按定位需要开启，因为它比单个事件字段更重。

import jdk.jfr.Recording;
import java.nio.file.Path;
import java.time.Duration;

try (Recording recording = new Recording()) {
    // 中文注释：CPU 采样每 2 秒取一次，适合先看趋势而非追逐瞬时尖峰
    recording.enable("jdk.CPUSample")
             .withPeriod(Duration.ofSeconds(2));
    // 中文注释：只保留达到 20 毫秒的文件写入，并关闭无关堆栈
    recording.enable("jdk.FileWrite")
             .withThreshold(Duration.ofMillis(20))
             .withoutStackTrace();
    // 中文注释：设置完成后再启动，避免录制初段使用了错误配置
    recording.setToDisk(true);
    recording.start();
    Thread.sleep(30_000L); // 中文注释：模拟一个有限复现窗口
    recording.stop();
    recording.dump(Path.of("jfr-sampled.jfr"));
} catch (InterruptedException ex) {
    // 中文注释：收到中断时恢复中断标记，让上层决定是否结束诊断
    Thread.currentThread().interrupt();
}

这段写法的边界是：period 只适用于周期事件，threshold 只对有持续时间的事件有意义；它们不会替代业务压测，也不会自动证明某个线程就是根因。若需要调用路径，再针对目标事件使用 withStackTrace()，不要全局打开。

用事件数量验证开销是否值得

调参后不要只看“生成了一个 .jfr 文件”。先确认文件里真的有目标事件，再判断字段和堆栈是否足够支持下一步。事件太少，说明周期或门槛过严；事件爆炸，说明范围、周期、阈值或堆栈开关过宽。

# 中文注释：只打印目标事件，先判断采样是否真的产生了记录
jfr print --events jdk.CPUSample,jdk.FileWrite jfr-sampled.jfr

# 中文注释：查看录制的元信息，核对起止时间和配置线索
jfr metadata jfr-sampled.jfr | head -n 40

常见问题

default.jfc 能不能直接替代所有 profiling？

不能。它适合持续记录的基础信号；需要更多事件时可以在短时间窗口使用 profile，或复制配置后只修改相关事件。

threshold 越大是不是越省开销？

通常会减少短耗时事件数量，但也可能漏掉大量频繁的小调用。应让门槛服务于问题边界，并用事件输出确认没有过滤过头。

为什么只调 period 仍然感觉记录很重？

可能是其他事件仍在记录，或堆栈信息带来了额外数据。先按事件名缩小范围，再单独决定哪些事件需要堆栈。

最终可以把规则固化为一张清单：持续观察用 default.jfc，短时复现才用 profile.jfc；周期事件调 period，耗时事件调 threshold，调用栈只给真正需要定位的事件；最后用 jfr print 检查记录是否足够。这样降低的是无效数据量，而不是牺牲诊断能力。