Java多态虚方法调用在HotSpot JVM中几乎无性能开销，因JIT能通过单态/多态内联缓存优化为直接调用；仅当类型频繁切换超4种（megamorphic）时才退化为vtable查找，但其本身仍为O(1)常数时间。

多态虚方法调用在Java中看似有性能隐患，实际在现代JVM（如HotSpot）中已被高度优化。关键不在于“有没有开销”，而在于“JIT在什么条件下能把它变成几乎零开销”。真正影响性能的，往往是代码结构、类型稳定性与JIT编译时机，而非多态本身。

单态内联：最常见也最高效的优化路径

当某个虚方法调用点（invokevirtual）在运行时**99%以上都指向同一个子类实现**，JIT就认定它是单态（monomorphic）的。此时会直接记录该类型对应的目标方法地址，后续调用跳过vtable查找，等效于静态调用。

• 典型场景：工厂返回固定类型实例（如new ArrayList<>()）、Spring Bean单例注入后的接口调用
• 触发条件：方法体不大（默认≤325字节）、无复杂控制流（如跨方法的try-catch）、接收者类型稳定
• 效果：调用开销趋近于直接跳转，和final方法差距极小（实测通常<5%）

双态与多态内联：有限分支仍可高效缓存

当一个调用点观察到**2–4个常见实现类型**（比如List接口常被ArrayList和LinkedList调用），JIT会启用多态内联缓存（polymorphic inline cache）。它把几个高频类型及其对应方法地址打包缓存，每次调用先比对类型，命中即跳转。

• 不是查表遍历，而是类似switch的快速类型判别（基于类指针比较）
• 仍保留内联机会：若某次编译时发现当前热点路径只用其中一种实现，仍可能临时单态化并内联
• 常见于策略模式、模板方法中不同子类混用但数量可控的场景

退化为megamorphic：何时放弃内联？

当JIT发现某个invokevirtual调用点**频繁切换超过4种以上类型**，或类型分布高度随机（如动态加载大量插件实现），就会标记为megamorphic。此时不再缓存具体目标，每次调用都走标准vtable查找。

• vtable查找本身仍是O(1)：一次内存寻址（类对象中存着vtable地址），L1缓存友好，耗时通常<1ns
• 真正代价是失去内联带来的连锁优化：逃逸分析失效、标量替换受阻、循环展开受限
• 常见诱因：泛型擦除后类型信息丢失、反射调用、ASM动态生成类、未预热的测试代码

验证与调优：别猜，用工具看真实行为

是否被优化，源码和字节码无法说明，必须依赖JVM运行时反馈。

• 加参数启动：-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation
• 日志里搜inline：看到reason: monomorphic或reason: type check fails就能确认决策依据
• 用jstack -l <pid>检查栈帧：出现Compiled frame表示已JIT编译，Interpreted frame说明还没热起来
• 简单压测对比：循环调用10万次，对比虚方法与final版本，差异显著超出±5%，大概率是GC、未预热或别的瓶颈