多态访问去优化是JIT修正推测的必要动作；需通过限制实现类、避免反射修改、显式类型断言等方式增强推测稳定性，而非简单判空。
多态访问的去优化不是错误，而是 JIT 在运行时“修正判断”的必要动作；防御性编码在这里不是写一堆 if 判空，而是提前暴露假设、控制变化范围、让 JIT 的推测更稳。
多态访问为何容易触发去优化
Java 中的虚方法调用（如 obj.process()）在编译期无法确定具体目标，JIT 必须靠运行时 profile 做推测。常见场景包括：
- 初始只见过
A.process()，JIT 内联了它，并省略类型检查；后来加载了类B，且B也实现了该方法，调用链就变了 - 对象字段被反射修改（如通过
Unsafe.defineAnonymousClass），导致原本稳定的隐藏类结构失效 - 记录类（record）模式匹配中，
instanceof Point(int x, int y)依赖字段顺序和类型，若后续通过动态代理或字节码增强插入新字段，匹配逻辑就可能被推翻
JIT 如何执行这次“回退”
去优化不是重启方法，而是在当前执行点做一次“上下文快照 + 映射还原”：
- 线程暂停，寄存器值与栈帧内容被冻结并转成解释器可读的格式
- 控制权交还给解释器，从**当前字节码位置**继续执行（不是重进方法头）
- 后续若再次变热，JIT 可能生成更保守的版本：比如放弃内联，改用内联缓存（Inline Cache）查表跳转；或插入显式类型检查（guard）再决定是否走优化路径
对应到防御性编码：别等 JIT 崩溃才补救
防御性编码在此处的核心是——减少 JIT 推测失败的“意外性”，把变化管住、把契约写明：
- 避免在热点路径中使用反射修改字段或方法签名，尤其不要在循环体内调用
setAccessible(true) - 对关键多态接口，用
sealed类或final方法限制实现类数量，让 JIT 更容易判定“单实现”或“有限实现” - 记录类（record）用于模式匹配时，不通过 ASM 或 Byte Buddy 动态重写其
canonical constructor或字段布局 - 在性能敏感模块中，用
-XX:+TraceDeoptimization观察日志，一旦发现频繁made not entrant，说明运行时行为超出了最初 profile 范围，该检查代码是否引入了隐式多态扩张
一个实际可操作的小习惯
在写抽象方法调用前，加一句带明确语义的断言，不是为了抛异常，而是给 JIT 提供“稳定信号”：
// 这不是冗余检查，是告诉 JVM：“此处预期只有 A/B 两类”if (!(obj instanceof A || obj instanceof B)) { throw new IllegalStateException("Unexpected subtype"); }
这类显式分支会让 JIT 更倾向于生成带 guard 的优化代码，而不是盲目内联后被逼着去优化。
