能，但必须显式启用且配置合理：java 11+需加-xx:+flightrecorder，动态录制须指定name、duration、settings等参数，分析用jmc而非浏览器，长期监控建议启动时固定开启。
能，但必须显式启用且配置合理 —— 默认不开启、不落盘、不命名的 JFR 录制在生产环境毫无实用价值。
启动前必须加 -XX:+FlightRecorder
Java 11+ 虽已开源 JFR，但默认仍禁用。不加这个参数，jcmd <pid> JFR.start</pid> 会直接报错“Unknown diagnostic command”，连基础命令都不可用。
- OpenJDK 17/21（如 Temurin、Zulu）通常内置支持，但容器镜像或构建脚本可能覆盖 JVM 参数，建议始终显式声明
- Java 8u261+ 需额外加
-XX:+UnlockCommercialFeatures，但生产环境应尽快升级到 11+ - 验证是否生效：
java -XX:+FlightRecorder -version不报错即通过
jcmd JFR.start 动态录制必须带 name 和 duration
不指定 name 和 duration 的录制是“盲录”：默认只录 60 秒、缓冲区仅约 10MB、无文件名、无上下文，事后根本无法区分哪次录制对应哪次故障。
-
name=cpu-spike-20260419-0015：便于归档和关联告警时间点 -
duration=180s：明确终止时间，避免无限录制拖垮老年代内存 -
settings=profile：比默认default多采集方法栈、锁竞争、TLAB 分配等关键事件，精度提升明显 -
maxsize=500M：防止磁盘写满；disk=false（默认）更安全——数据先走内存环形缓冲，开销更低
分析 .jfr 文件别用浏览器打开
JFR 录制 3 分钟高负载应用，轻松产出 100MB+ 的二进制文件。浏览器加载 .jfr 会触发前端 JS 渲染大量事件（比如 5 万次 jdk.ThreadParkEvent），极易卡死或 OOM。
- 必须用本地
jmc（JDK Mission Control）：它做流式解析 + 懒加载，支持 500MB+ 文件 - 快速筛关键数据：
jfr print --events "jdk.CPULoad,jdk.GarbageCollection" recording.jfr - 导出结构化数据：
jfr export --events jdk.MethodSample recording.jfr --output method.csv，再用 Excel 或 Grafana 分析
低开销 ≠ 零开销，高频或全量录制会反噬性能
默认 profile 配置下开销约 0.5%–1%，但若误设 disk=true + maxsize=0（无限落盘），或在 CPU 已达 90% 的节点上每 30 秒启停一次录制，JVM 线程会频繁刷盘、GC 压力陡增。
- 长期监控推荐 JVM 启动时固定开启：
-XX:StartFlightRecording=delay=0s,duration=0s,filename=/var/log/jfr/app.jfr,maxsize=2G,settings=profile（duration=0s表示持续录制） - 突发问题排查才用
jcmd动态启停，且单次不超过 5 分钟 - 若进程意外崩溃，
disk=false下未刷盘的缓冲区数据会丢失 —— 这是低开销设计的必然取舍，不是 bug
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
