JVM预热本质是解释执行与JIT编译的CPU资源争夺，需用轻量JFR profile模板（-XX:StartFlightRecording=duration=90s,settings=profile -XX:FlightRecorderOptions=stackdepth=128）聚焦Compilation、ClassLoading、ThreadPark三类事件，结合-XX:+PrintCompilation日志交叉验证，定位类加载阻塞、编译阈值过高或ForkJoinPool抢占等真实瓶颈。
JVM 预热阶段的 JIT 编译峰值和延迟，本质是解释执行与编译决策之间的资源争夺——用户请求线程抢 CPU，编译线程也抢 CPU，结果谁都没跑快。用 JFR 不是为了“看有没有编译”，而是要定位“哪些方法在什么时机被卡住编译”“谁在阻塞编译线程”“类加载是否拖慢了编译触发”。关键不在开不开 JFR，而在怎么录、录什么、怎么看。
JFR 启动配置必须轻量且覆盖关键事件
冷启动期间开全量 JFR 会反向拖慢本身，必须用 profile 模板+采样模式，聚焦 JIT 和类加载主线：
- 加参数：-XX:+FlightRecorder -XX:StartFlightRecording=duration=90s,filename=/tmp/startup.jfr,settings=profile -XX:FlightRecorderOptions=stackdepth=128
- profile 模板默认 10ms 方法采样，不记录每行字节码，但能抓到热点方法栈和编译入口点
- 务必设 stackdepth=128，否则 Spring Bean 初始化链中深层反射调用会截断，看不到真实瓶颈位置
- 输出路径用 /tmp/ 而非当前目录，避免容器环境权限或磁盘满导致录制静默失败
重点筛查三类 JFR 事件时间轴
打开 .jfr 文件后，不要先看火焰图。先按时间线过滤以下三组事件，确认是否存在串行阻塞或异常延迟：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- Compilation 事件：查看首次 CompilationStarted 到 CompilationFinished 的耗时，若单个方法 >500ms，说明该方法含大量泛型推导或 ASM 字节码操作
- ClassLoading 事件：筛选 “loadClass” 类型，检查是否有某类加载耗时 >200ms（常见于未预加载的 Spring Boot 自动配置类）
- ThreadPark + JavaMonitorEnter：若 JIT 编译线程（C2 CompilerThread0）频繁 Park 或等待 Monitor，说明它正被 GC 线程或 ClassLoader 加锁阻塞
从火焰图识别 JIT 延迟的真实归因
火焰图里“高而窄”的 JIT 编译条不危险，“矮而宽”且底部堆着大量 java.lang.ClassLoader.loadClass 或 sun.reflect.ReflectionFactory.newConstructorForSerialization 才是问题：
立即学习“Java免费学习笔记（深入）”；
- 如果顶层是 CompilerThread::compile_task，但下方 70% 栈帧是 SystemDictionary::resolve_instance_class_or_null → 说明类加载器查类型字典太慢，需预加载关键类
- 如果火焰图中反复出现 java.util.concurrent.ForkJoinPool.runWorker 占比突增 → 表明虚拟线程或 CompletableFuture 初始化抢占了编译线程资源，需预热 ForkJoinPool
- 若大量方法停留在 Interpreter::dispatch_next，但 CompilationStarted 事件极少 → 说明 CompileThreshold 设得太高（默认 10000），应降至 3000–5000 并配合 TieredStopAtLevel1
结合日志做交叉验证
JFR 是黑盒运行时证据，日志是白盒执行痕迹。二者对齐才能下结论：
- 在 JVM 参数中加 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation，生成 hslog.xml
- 用工具如 JITWatch 加载 hslog.xml，标出“首次编译耗时最长的前 5 个方法”
- 回到 JFR 火焰图，搜索这 5 个方法名，看它们是否出现在用户首请求的调用链中；若出现但未被及时编译 → 就是预热缺口
- 若发现某个方法在 JITWatch 中已编译，但在 JFR 里无 CompilationFinished 事件 → 可能被 C2 编译器跳过（如含 Unsafe 操作），需加 -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading
