必须回退是因为JIT优化基于强假设（如类型、类结构、对象布局），一旦运行时变更导致假设失效，继续执行会引发语义错误；回退是同步暂停线程、快照状态、映射回字节码并精确续执的现场重置过程，而非降级。
当变量类型或类的状态在运行时发生变更（比如子类被动态加载、对象实际类型与 JIT 推测不符），JIT 编译器不会尝试“修补”已生成的机器码，而是立即中止执行，重建解释器栈帧并切回解释模式——这个过程就是反优化（deoptimization）。
为什么必须回退，而不是继续执行？
JIT 的优化建立在强假设之上，例如：
- 某个引用变量始终指向 String 类型，于是省略了类型检查、直接调用
String.length()的内联版本； - 虚方法调用（如
obj.foo()）被推测只有 A 类实现，于是内联了A::foo并插入了类检查守卫（class guard）； - 字段访问被优化为固定内存偏移，前提是对象布局（即隐藏类 / klass）未变。
一旦新子类被 ClassLoader.defineClass 加载，或某个变量首次赋值为 Integer 而非预期的 int，这些假设就失效。继续执行原机器码会导致语义错误（如越界读、非法转型、跳转到不存在的方法），所以 JVM/V8/CPython JIT 必须保证正确性优先，宁可慢，不可错。
回退不是“降级”，而是“现场重置”
Deoptimization 不是切换到低优化等级的编译版本，而是同步暂停线程，完成三步关键操作：
- 快照寄存器与栈状态：把当前 CPU 寄存器、栈顶指针、局部变量槽（locals array）内容全部捕获；
-
映射回字节码语义：将机器码中的 SSA 值反向还原为解释器能理解的
PyFrameObject或InterpreterFrame结构，包括恢复f_lasti（当前字节码索引）； - 交还控制权：从精确的字节码位置继续执行（不是重进方法头），确保程序行为与纯解释执行完全一致。
这意味着：哪怕只在循环第 10001 次迭代时触发一次 deopt，整个循环体后续所有迭代都走解释路径，性能断崖式下跌。
典型触发场景与底层诱因
以下变更会直接导致守卫失败，触发强制回退：
- 类层次变动：新子类加载后，原先“单实现”的虚方法调用不再成立，内联代码中的 class guard 检查失败；
- 对象形状突变（V8）：给对象动态添加属性，破坏隐藏类链，导致内联缓存（IC）失效并触发 bailout；
-
逃逸结论反转：JIT 原认为某对象仅在线程栈内使用，结果它被传入
Thread.start()或写入静态字段； -
反射或 Unsafe 扰动：通过
Unsafe.defineAnonymousClass修改字段类型，或用反射篡改 final 字段，使字段访问优化失效。
如何验证和定位这类问题
开启对应日志是最有效方式：
- Java HotSpot：
-XX:+TraceDeoptimization -XX:+PrintCompilation，关注输出中的deoptimize、made not entrant、reason=class_check； - V8：
--trace-deopt --print-opt-code，观察bailout点和deoptimize reason； - Python 3.15 实验 JIT：
PYTHONJITLOG=1，查找deoptimize: function 'xxx', reason 'freevar_mismatch'。
若单次函数调用内 deopt 计数持续增长（如 >3），基本说明存在不可收敛的类型震荡，JIT 在反复编译-失败-重建，CPU 时间大量消耗在元操作上。
