jit 优化不是“一劳永逸”因为其依赖的运行时推测信息可能失效，一旦假设被违反（如类型变化、类加载、虚方法目标变更等），必须执行去优化（deoptimization）回退到解释执行。
热点代码识别后，JIT 为什么不是“一劳永逸”地优化？
JIT 编译器（如 HotSpot 的 C1/C2 或 V8 的 TurboFan）不会把所有代码都编译，只对被反复执行的热点代码（比如循环体、高频调用的方法）触发编译。但“热点”只是触发条件，不是信任状——JIT 的优化基于运行时收集的profile information（如变量类型、分支走向、对象布局），这些信息是推测性的、有前提的。
一旦后续执行违反了当初的假设（比如某个int变量突然装箱成Integer，或子类被动态加载），已生成的优化代码就不再安全，必须退回到解释执行或低优化层级，这个过程就是deoptimization。
常见诱因包括：
- 类继承关系变化（如通过
ClassLoader.defineClass动态加载新子类） - 字段类型或方法签名在运行时被反射修改（如
Unsafe.defineAnonymousClass） - 内联的虚方法实际目标发生变更（原以为只有
A.foo()，后来B.foo()也被调用） - 逃逸分析结论失效（原本判定对象不逃逸，后来被传入
Thread.start()）
Java HotSpot 中 deoptimization 的典型触发路径
HotSpot 的 deoptimization 不是“重编译”，而是“现场快照 + 栈上替换（OSR）回退”。当检测到假设失败（例如ClassCastException在优化代码中本该被省略，却真实抛出），JVM 会：
- 暂停当前线程，在执行点记录寄存器和栈帧状态
- 将已优化的机器码执行上下文，映射回解释器能理解的
BytecodeInterpreter栈帧格式 - 把控制权交还给解释器，从当前字节码位置继续执行（不是从方法头重来）
- 后续若再次变热，可能触发新一轮编译，但这次会放宽假设（如放弃类型推测，插入类型检查）
可通过-XX:+PrintCompilation -XX:+TraceDeoptimization观察日志中的made not entrant或deoptimize字样。注意：deoptimization本身开销不小——一次栈重建可能耗时数百纳秒，频繁发生会抵消 JIT 带来的收益。
V8 的 lazy deoptimization 与 on-stack replacement 差异
V8 对 deoptimization 的处理更激进：它不等错误发生，而是在生成优化代码时就埋入多个deoptimization bailout点（比如在每次属性访问前检查对象隐藏类是否匹配）。一旦检查失败，立即跳转到bailout stub，执行栈帧重建并回落到Ignition解释器。
关键区别在于：
- HotSpot 的 deopt 多由异常或断言失败驱动；V8 则是主动、细粒度的守卫（guard）检查
- V8 的 OSR 允许在循环中间退出优化代码，HotSpot 的 OSR 主要用于进入长循环体，退出支持较弱
- V8 会为同一函数维护多份优化版本（
optimized code），按 profile 分支缓存；HotSpot 默认只保留最新一份，旧版本标记为not entrant后等待 GC
这意味着：在 V8 中，一个for循环里混用{x:1}和{x:1, y:2}对象，可能导致多次 bailouts；而在 HotSpot 中，如果初始 profile 记录的是单类型，后续混用可能直接导致deoptimization并降级为解释执行。
写代码时哪些操作会悄悄招来 deoptimization？
多数 deoptimization 不是你主动写的，而是框架或运行时行为间接引发的。容易被忽略的高风险点：
- 使用
java.lang.reflect.Method.invoke()调用已被内联的方法（破坏内联假设） - 在 Lambda 表达式中捕获可变外部变量（影响逃逸分析和标量替换）
- 频繁用
System.setProperty()修改 JVM 属性（某些属性变更会触发全局 deopt，如java.util.stream相关 flag） - 在 GraalVM Native Image 中未正确配置
@ReachabilityPolicy，导致运行时类加载失败后 fallback 到 deopt 路径
真正难调试的是“隐式去优化”：没有异常、没有日志，只是吞吐量掉 20%，CPU 火焰图显示解释器帧突然变厚——这时候得开-XX:+PrintOptoAssembly或 V8 的--trace-deopt，盯着那些被反复废弃的编译单元。
