jit“罢工”指热点方法反复退优化、长期解释执行、cpu升高、吞吐骤降；根本原因是显式绑定（super/interface.super/强制转型）导致调用链不可预测，使jit无法稳定推断目标方法而放弃内联或编译，典型信号为日志中大量made not entrant、failed to inline及jstat显示compiled停滞、failed上涨。
JIT 编译器“罢工”不是崩溃或报错，而是热点方法反复退优化、长期解释执行、CPU 升高、吞吐骤降——在复杂领域模型继承体系中，高频交叉调用 + 显式绑定（如 super.xxx()、Interface.super.xxx()、强制类型转换后调用）极易触发 JIT 的保守策略，导致编译器放弃内联甚至拒绝编译。
关键不在“调用多”，而在“调用链不可预测”：显式绑定常伴随虚方法表跳转、接口默认方法多态分派、泛型擦除后类型模糊等行为，JIT 编译器无法稳定推断目标方法，最终选择不编译。
看得见的信号：先确认是不是 JIT 罢工
启动时加参数：
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:CompileCommand=print,*YourDomainClass.*
运行后观察日志：
✅ 正常：出现compiled、inline (hot)、nmethod size等记录
❌ 罢工：大量made not entrant、failed to inline: too many arguments、reason: virtual call too complex、reason: unstable class hierarchy实时检查编译状态：
jstat -compiler <pid></pid>→ 若Compiled停滞、Failed持续上涨，说明 JIT 已进入防御模式jstat -codecache <pid></pid>→ 若Used / Max > 85%或largest_free_block ，说明 CodeCache 碎片化严重，JIT 不敢分配新空间
根因拆解：为什么显式绑定会劝退 JIT？
-
super.xxx()在多层继承中仍属虚调用，JIT 需校验类继承链是否稳定；若存在运行时 redefine（如 Spring DevTools、热部署）、动态代理（AOP），JIT 会标记为unstable并拒绝内联 -
Interface.super.xxx()（JDK 21+）虽语法明确，但底层仍是 interface dispatch，且需额外查表定位，默认方法可能被子类重写，JIT 无法做单目标内联 - 强制转型后调用（如
((OrderProcessor) handler).validate()）引入类型检查字节码（checkcast+invokevirtual），增大方法体积与控制流分支，超过MaxInlineSize或触发too deep in call chain
实战修复策略：让 JIT 重新信任你的调用链
-
收敛调用入口，避免“到处 super”
把跨层级的显式绑定逻辑收拢到少数稳定方法中，例如：// ❌ 遍地 super.validate()、super.enrich() class PremiumOrder extends Order { void process() { super.validate(); // JIT 看到的是 Order.validate()，但不确定它是否被重写 super.enrich(); } } // ✅ 收口为 final 方法，明确告诉 JIT：这里不会变 abstract class Order { final void safeValidate() { validate(); } // final → 可内联 final void safeEnrich() { enrich(); } protected abstract void validate(); protected abstract void enrich(); } -
用静态分发替代动态绑定
对高频交叉调用场景（如状态机 transition、策略路由），改用switch或查找表驱动：// ❌ 多态调用链深、JIT 难预测 order.getState().onEvent(event); // ✅ 静态 dispatch，JIT 可完全内联 switch (order.getState()) { case PENDING -> handlePending(event); case CONFIRMED -> handleConfirmed(event); case CANCELLED -> handleCancelled(event); } -
规避泛型擦除干扰
泛型类型参数参与继承时（如abstract class Entity<t></t>），子类User extends Entity<user></user>在运行时仍是Entity，JIT 无法区分具体类型。解决方式：- 关键路径避免泛型方法直接参与热点调用
- 必须泛型时，用
@SuppressWarnings("unchecked")+ 显式 cast 后调用final方法，而非泛型抽象方法
必要时主动排除干扰项
若某段显式绑定逻辑确实无法重构（如兼容老版本接口），可用编译指令隔离：-XX:CompileCommand=exclude,com.example.domain.OrderProcessor::legacyFallback
让 JIT 专注优化其余稳定路径，避免因局部不稳定拖垮整体编译节奏
上线前必做三件事
- 用
async-profiler抓取 60 秒火焰图，确认热点是否从Interpreter区域转移到C2N（JIT 编译代码）区域 - 对比开启
-XX:TieredStopAtLevel=1（仅解释器）和=3（C1 编译）下的吞吐差异，验证优化有效性 - 在预发环境跑 30 分钟压测，持续采集
jstat -compiler和jstat -gc，确保Failed为 0、Compiled稳定增长、GC 次数未异常上升
JIT 不是黑箱，它只拒绝不可信的代码。把调用链变得可预测、可收敛、可验证，它自然就会回来。
