Java虚方法调用慢的根源在于每次需类型判断、查表和校验；内联缓存（IC）是解释器生成的可修改机器码桩，非传统缓存，仅在解释执行阶段生效，单态时开销≈直接调用，多态退化则显著增开销。
Java虚方法调用为什么慢？内联缓存不是JVM的“缓存”，而是硬件+解释器协同机制
Java里 invokevirtual 指令执行虚方法调用时，不能像 invokestatic 那样直接跳转——因为目标方法在编译期未知，得靠运行时查虚方法表（vtable）或接口方法表（itable）。但查表本身不慢，真正拖慢的是“每次都要做类型判断 + 查表 + 校验”。内联缓存（Inline Cache）本质不是存结果的缓存，而是一小段可修改的机器码桩（stub），用来快速拦截“上次见过的类型”。
它由解释器生成并维护，HotSpot里叫 ICStub，和JIT编译无关。JIT编译器后续会基于IC的命中统计决定是否内联、是否生成多态/超多态优化代码。
- 常见错误现象：
javap -c看不到IC——因为它只存在于解释执行阶段的机器码中，字节码层面完全不可见 - 使用场景：仅对解释执行路径生效；一旦方法被JIT编译，IC就退场，由C1/C2的去虚拟化（devirtualization）接管
- 性能影响：单态IC（monomorphic）下，虚调用开销≈直接调用；但如果频繁切换实现类（如List接口来回用
ArrayList/LinkedList），IC会退化为“复态”甚至“超多态”，触发去优化和重新查表
怎么观察内联缓存是否生效？看 -XX:+PrintInterpreter 和 -XX:+TraceClassLoading 日志里的 IC miss 记录
IC是否活跃、是否命中、是否退化，只能通过JVM底层日志确认。启动参数加 -XX:+PrintInterpreter -XX:+TraceClassLoading，然后跑一段稳定调用同一子类方法的代码（比如循环调用 list.get(0) 且 list 始终是 ArrayList 实例）。
你会在日志里看到类似：
立即学习“Java免费学习笔记（深入）”；
IC miss for invokevirtual java/util/List.get(I)Ljava/lang/Object; @ bci=12, receiver=java/util/ArrayList
首次执行就是IC miss，之后再调就会变成 hit；如果日志持续刷 miss，说明没稳定类型，IC始终无法固化。
- 容易踩的坑：用JUnit单测跑一次就停——JVM还没来得及填满IC，日志全是miss；要循环足够多次（通常 >1000），且确保对象类型不变
- 参数差异：
-XX:InlineSmallCode=1000这类参数不影响IC，它只影响JIT内联决策；IC行为由解释器控制，和-XX:+UseInterpreter强相关 - 兼容性影响：ZGC/Shenandoah等新GC不影响IC逻辑，但GraalVM Native Image默认不带解释器，
invokevirtual直接走静态分发或预生成桩，IC根本不存在
为什么加了 final 或私有方法就不走内联缓存？因为压根不走 invokevirtual
final 方法、private 方法、构造器、静态方法，字节码指令分别是 invokevirtual（但语义上可绑定）、invokespecial、invokestatic。只有 invokevirtual 和 invokeinterface 才需要IC支持。
所以给方法加 final 的真实收益，不是“让IC更快”，而是让JVM彻底绕过虚调用流程——连IC桩都不生成，直接硬编码跳转地址（解释器）或编译期绑定（JIT）。
- 常见错误现象：以为加
final是“帮IC提速”，其实它是把IC整个移除 - 使用场景：适合明确不会被继承/重写的方法；但别为了“优化”滥用
final，破坏扩展性得不偿失 - 性能影响：
invokespecial比单态IC还快一丁点，但差距微乎其微；真正省下的是IC维护开销和退化风险
内联缓存失效的三个典型信号：日志里反复出现 IC miss、IC stub replaced、deoptimization
IC不是永久有效的。当JVM发现某个虚调用点接收了新类型实例（比如之前都是 ArrayList，突然来了个 Vector），就会触发IC stub替换——旧桩失效，新桩重建。更严重时，已编译的JIT代码会因类型假设失败而被去优化（deoptimization），退回到解释执行，重新积累IC数据。
这过程不报错，但会悄悄拖慢吞吐量。尤其在微服务高频RPC场景下，DTO对象类型稍有混杂（比如不同版本的序列化类），就容易引发IC震荡。
- 容易踩的坑：用
Object接收后强转再调用——类型信息丢失，IC永远看不到稳定receiver，必然退化 - 使用场景：框架层（如Spring AOP代理）常无意中打破类型稳定性；建议用
@SuppressWarnings("unchecked")显式声明类型意图，比靠IC猜更可靠 - 性能影响：IC从单态→复态→超多态，虚调用开销可能从1~2ns涨到20+ns；虽仍远低于反射，但对延迟敏感路径已是瓶颈
真正难处理的不是IC怎么工作，而是它不工作的样子——没有异常、没有警告，只有吞吐量缓慢下滑和JIT日志里一闪而过的 IC stub replaced。这时候得翻 -XX:+PrintCompilation 和 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，才能定位到哪行 invokevirtual 被放弃了。
