最直接方式是启用-XX:+PrintCompilation查看控制台编译日志，如“123 45 3 java.lang.String::hashCode (67 bytes)”，其中数字3表示C1编译层级；若同一方法在1/3/4层反复出现，说明JIT因profile不稳定而摇摆。
怎么看JIT是否正在编译或失效
最直接的方式是打开JIT日志，而不是等P99飙升后再翻GC日志。JIT编译本身不报错，但会留下明确的编译事件痕迹——关键在于你得让JVM把它们吐出来。-XX:+PrintCompilation 是底线配置，它会在控制台输出类似 123 45 3 java.lang.String::hashCode (67 bytes) 这样的行：数字是编译序号，第二个是方法ID，3 表示C1编译层级，后面是方法签名和字节码大小。如果看到大量重复方法反复出现（尤其是同一方法在1、3、4层来回跳），基本就是编译器在“摇摆”，说明profile信息不稳定，比如多态调用点实际类型频繁变化。
为什么加了-XX:+PrintCompilation还看不到热点方法
常见原因有三个：-Xcomp 强制提前编译会压制解释执行阶段的计数，导致热点探测失灵；-XX:-TieredCompilation 关掉分层后，C2直接接管，但触发阈值更高（默认10000次调用），短生命周期服务可能根本等不到；更隐蔽的是-XX:CompileThreshold=1000 这类手动调低阈值的参数，反而会让JIT过早介入，编译出质量差的代码，后续被C2推翻重编，造成CPU毛刺。真实线上环境建议保留默认分层，只加-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation，后者生成hotspot-pid12345.xml，可用jitwatch可视化分析编译时序和失效原因。
CodeCache打满却不报错，怎么定位是JIT问题
CodeCache耗尽不会抛异常，只会静默禁用JIT，所有新方法退回到解释执行，性能断崖下跌。不能只看jstat -compiler里failed字段，它只统计编译失败次数，不反映碎片化。必须用jcmd 查三段使用率：NonProfiledCode（未带profile的机器码）、ProfiledCode（带分支/类型profile的C1/C2混合码）、NonNMethodCode（stub、adapter等）。如果三段使用率都低于90%，但largest free block只有几KB，就是典型碎片——JIT想编译一个20KB的方法，却找不到连续空间，只能放弃。这时配合-XX:+UseG1GC -XX:+UseCodeCacheFlushing才能缓解，单独加大-XX:ReservedCodeCacheSize没用。
方法内联失效导致的延迟抖动怎么确认
内联是JIT最基础也最关键的优化，失效会直接让调用开销从纳秒级回到微秒级。检查方式很具体：-XX:+PrintInlining 会输出每处调用是否被内联及原因，例如failed: hot method too big 或 not inlineable: call site not stable。特别注意反射调用（Method.invoke）、Lambda工厂（LambdaMetafactory.metaFactory）和接口默认方法，这些在运行期绑定的调用点，一旦目标实现类动态变更（如Spring AOP代理切换），JIT会立刻撤销已内联的代码并回退到虚表查找。这种抖动往往伴随made not entrant和made zombie日志，意味着旧编译版本正在被卸载。
JIT造成的波动从来不是“突然变慢”，而是“编译-失效-重编”的循环过程。最容易被忽略的是：它不依赖代码变更，只依赖运行时行为变化。一次配置热更、一个新加载的插件、甚至只是某个接口返回了不同子类实例，都可能成为触发点。
