热替换后代码不生效很可能是JIT内联导致的“假失效”，需通过-XX:+PrintInlining等参数确认内联状态并触发去优化重编译。
热替换后代码不生效，但日志或调试显示执行的仍是旧逻辑，很可能是 JIT 已将旧版本方法内联进调用方，而类重定义（如 JRebel、Spring DevTools 或 JVM TI 热更）只替换了被调用方法本身，没刷新已编译的调用者机器码。
确认是否是 JIT 内联导致的“假失效”
启用内联诊断，观察目标方法是否已被内联且未被去优化：
- 加 JVM 参数：-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions
- 触发热替换后，再高频调用该方法（例如循环 10 万次），观察控制台输出中是否有类似：
@ 5 com.example.Service::process (28 bytes) inline (hot)
若存在且后续调用仍走旧逻辑，说明 JIT 编译后的代码已固化，未感知类变更 - 同时检查是否有 deoptimize 日志——没有则大概率未触发去优化
强制让 JIT 感知类变更并重新编译
JIT 默认不会主动监听类重定义事件，需通过机制触发去优化（deoptimization）和重编译：
- 对关键方法添加 volatile 标记字段或调用 System.nanoTime() 等易变操作，打破 JIT 的逃逸/常量假设，促使其放弃激进优化
- 使用 -XX:+UseBiasedLocking -XX:-UseOptoBiasInlining 降低偏向锁相关内联深度（部分热更场景下可缓解）
- 在热替换后，主动调用 ManagementFactory.getCompilationMXBean().getTotalCompiledMethodCount() 并做一次空循环（如
for (int i = 0; i ），制造轻量级“编译压力”，促使 C2 重新评估热点
规避内联依赖的设计策略
从编码层面减少对 JIT 内联稳定性的依赖：
- 避免在热更敏感路径上直接调用可能被内联的 public final 或 private static 工具方法；改用接口+简单实现类，靠多态调用（JIT 对虚方法去优化更积极）
- 将易变业务逻辑封装进非 final 实例方法，并确保该类无子类（CHA 可证明不可覆盖），既保留一定内联机会，又支持热更时被安全去优化
- 对 getter/setter 等极简方法，显式加 @HotSpotIntrinsicCandidate 无意义，反而应加 final + 避免继承，否则 JIT 可能因虚调用拒绝内联，导致热更后调用跳转延迟可见
验证与兜底方案
上线前或问题复现时快速定位：
- 用 jstack -l
查看线程栈，确认执行点是否落在 Compiled frame（已编译）还是 Interpreted frame（解释执行）—— 若大量调用仍在 Compiled frame 却逻辑未更新，基本锁定 JIT 固化问题 - 临时启用 -XX:TieredStopAtLevel=1（停在 C1 编译层），C1 生成代码较简单、去优化更及时，适合开发/测试环境验证热更行为
- 生产环境慎用，但可作为紧急回滚手段：-XX:+UnlockDiagnosticVMOptions -XX:+ResetHotSpotCompiler 可清空 JIT 缓存（需 JDK 8u292+ 或 JDK 11+）
