必须回退是因为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 时间大量消耗在元操作上。