jit去优化是保障正确性的核心机制：当多态调用的乐观假设被打破（如新子类加载、反射介入等），已编译代码安全回退至解释执行并重新编译。

JIT 编译器在处理多态访问（如虚方法调用、接口调用）时，会基于运行时观察到的类型分布做激进优化——比如假设某个 `invokevirtual` 总是调用 `ArrayList.add()`，于是直接内联该实现，并省略类型检查。但一旦后续出现 `LinkedList.add()` 这类新类型，原有编译代码就不再安全，必须立刻退回到解释执行模式。这个“热代码回退+重新编译”的过程，就是去优化（deoptimization）。 它不是错误，而是 JIT 保障正确性的核心机制：用可逆的乐观假设换取性能，再用安全回退兜底。

多态访问触发去优化的典型场景

以下情况容易让已编译的热点代码失效：

• 类加载延迟：应用启动后动态加载新子类（如插件机制、OSGi），导致原单实现假设被打破
• 反射或动态代理介入：通过 Method.invoke() 或 CGLIB 生成新实现类，绕过原有类型链路
• 运行时类重定义（RedefineClasses）：JVM TI 工具（如 Arthas、JRebel）修改类结构，使已编译代码中的类型断言失效
• 极不均衡的类型分布突变：原本 99.9% 是 HashMap 调用，突然大量 ConcurrentHashMap 实例涌入

去优化的实际开销与可观测信号

一次去优化涉及栈帧重建、局部变量恢复、解释器接管，通常耗时 0.1–2ms。高频发生时会明显拖慢吞吐，常见表现有：

• JVM 日志中频繁出现 Deoptimizing method 或 made not entrant 记录（需开启 -XX:+PrintCompilation -XX:+TraceDeoptimization）
• GC 日志中伴随大量 Full GC 或 G1 Evacuation Pause —— 因去优化释放的编译代码占用 CodeCache，可能触发清理
• 火焰图中出现异常高的 Interpreter::entry 或 SharedRuntime::deopt_blob 占比

降低多态去优化频率的实用策略

目标不是杜绝去优化（不可能也不必要），而是减少其发生频次和影响范围：

• 稳定虚方法调用链：对关键热点路径，用 final 修饰方法或类，或使用密封类（sealed classes）限制子类数量，帮助 JIT 做更持久的单实现假设
• 避免运行时注入新实现：慎用 Unsafe.defineAnonymousClass、动态生成代理类；若必须，将这类逻辑隔离在非热点区域
• 预热阶段覆盖典型类型：在应用启动后、流量接入前，主动调用各常见子类的对应方法（如分别调用 ArrayList.add()、LinkedList.add() 各数百次），促使 JIT 提前完成多版本编译（TieredStopAtLevel=1 可辅助）
• 监控并识别“伪多态”：用 -XX:+PrintMethodData 查看某方法的 profile 数据，若 receiver types 显示仅 1–2 种类型长期占主导，说明实际并非真多态，可考虑重构为静态分发（如策略枚举 + switch）

理解去优化与 AOT 的本质差异

AOT（如 GraalVM Native Image）在构建期就固化所有类型决策，无法响应运行时变化，因此天然规避去优化——但也失去动态适应能力。而 JIT 的去优化恰恰是其灵活性的代价与证明：它敢激进，是因为能安全撤退。