compilationmxbean 提供 gettotalcompilationtime() 等聚合指标监控 jit 编译总耗时，支持判断编译开销占比是否超 3%–5%，但不暴露单个方法编译耗时；需结合 -xx:+printcompilation 或 jitwatch 进行细粒度分析。
CompilationMXBean 是 Java 平台管理接口（JMX）中用于监控 JIT 编译行为的核心组件，它不直接暴露单个方法的编译耗时，但能提供全局、聚合维度的关键编译性能指标——尤其适合识别 JIT 是否成为系统瓶颈。
CompilationMXBean 能监控哪些 JIT 时间相关变量
该 Bean 主要通过以下属性反映编译开销：
- getTotalCompilationTime()：自 JVM 启动以来，所有 JIT 编译任务累计消耗的毫秒数（总编译时间）
- isCompilationTimeMonitoringSupported()：返回 true 表示当前 JVM 支持编译时间统计（HotSpot 默认开启）
- getCompilationTimeMonitoringEnabled()：运行时是否启用编译时间采集（可通过 -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation 配合验证）
为什么它不能直接看到“某个函数编译花了多少毫秒”
JIT 编译是后台异步执行的，且 HotSpot 不在 CompilationMXBean 中暴露细粒度的 per-method 编译耗时。原因包括：
- 编译决策依赖运行时采样与计数器（如调用次数、回边次数），不是按函数调用即时触发
- 一个方法可能被 C1 和 C2 多次编译（分层编译），时间分散且不可简单叠加
- 真正需要关注的是“编译开销是否持续增长”，而非单次编译快慢
如何结合 CompilationMXBean 判断 JIT 时间损耗异常
重点看两个趋势关系：
- 若 getTotalCompilationTime() 在稳定流量下仍线性上升（如每分钟增加 >500ms），说明 JIT 持续编译新热点，可能未充分预热或存在动态生成代码（如反射、CGLIB）
- 对比 RuntimeMXBean.getUptime()，计算编译时间占比：超过 3%–5% 就值得警惕（例如 uptime=600000ms，compilation=35000ms → 占比 5.8%）
- 配合 HotSpotDiagnosticMXBean.getVMOption("CompileThreshold") 确认触发阈值，再查 HotSpotDiagnosticMXBean.getVMOption("TieredStopAtLevel") 判断是否卡在低层级编译
需要更细粒度？用替代方案补足
CompilationMXBean 是入口，但定位具体高耗函数需组合其他手段：
- 启用 -XX:+PrintCompilation：输出每次编译的方法名、层级、耗时（单位 ms）、是否失败
- 解析 -XX:+LogCompilation 生成的 hslog.xml，用 JITWatch 可视化分析各方法编译延迟与优化路径
- 对关键服务启动后主动调用核心方法（预热），避免首请求触发 JIT 延迟；可用 JMH 或简单循环触发
