反优化（Deoptimization）是指JIT编译器在运行期发现之前所做的优化假设不再成立时，将已经编译好的优化机器码作废，退回到解释执行或重新编译状态的过程。当某个变量在编译时被假设为特定类，而运行期该类层次结构发生变化，例如加载了子类，JIT必须能够识别并强制回退。
为什么类状态变更会破坏JIT优化
JIT在编译热点方法时常做类型特化优化，例如把虚方法调用直接内联为具体类的方法体，前提是“某变量永远是类A的实例”。如果 later 运行时通过ClassLoader加载了A的子类B，且变量实际指向B，原内联就违背了多态语义。
常见触发场景
- 父类被重新定义或增强（如Instrumentation）
- 动态加载子类导致方法表变更
- 反射修改字段布局
JIT如何检测并强制回退
HotSpot等虚拟机在编译时会插入守卫条件，当类状态发生变更，相关类的_is_being_redefined或子类链表更新会令守卫失败，进入反优化陷阱。
核心逻辑示例
// 伪代码：JIT生成的守卫与回退
if (obj.getClass() != A.class) {
// 触发反优化，回到解释器
Deoptimization::deoptimize_frame(frame);
return;
}
// 否则执行内联的A.method()
当新子类B加载，A的子类链变化，JIT失效栈上所有基于A假设的补丁，线程回到解释器重新收集_profile。
反优化对性能的影响
| 阶段 | 执行方式 | 开销 |
|---|---|---|
| 优化后 | 机器码 | 低 |
| 反优化瞬间 | 退解释器 | 高 |
| 重新编译 | 新机器码 | 中 |
反优化不是错误，而是JIT在动态语言特性下的安全网。
理解变量类状态变更引发的回退逻辑，能帮助我们在使用动态代理、OSGi等场景时减少不必要的类加载抖动。
deoptimizationJITclass_loading修改时间：2026-07-30 12:48:23