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方法差距极小（实测通常
双态与多态内联：有限分支仍可高效缓存
当一个调用点观察到**2–4个常见实现类型**（比如List接口常被ArrayList和LinkedList调用），JIT会启用多态内联缓存（polymorphic inline cache）。它把几个高频类型及其对应方法地址打包缓存，每次调用先比对类型，命中即跳转。
- 不是查表遍历，而是类似switch的快速类型判别（基于类指针比较）
- 仍保留内联机会：若某次编译时发现当前热点路径只用其中一种实现，仍可能临时单态化并内联
- 常见于策略模式、模板方法中不同子类混用但数量可控的场景
退化为megamorphic：何时放弃内联？
当JIT发现某个invokevirtual调用点**频繁切换超过4种以上类型**，或类型分布高度随机（如动态加载大量插件实现），就会标记为megamorphic。此时不再缓存具体目标，每次调用都走标准vtable查找。
- vtable查找本身仍是O(1)：一次内存寻址（类对象中存着vtable地址），L1缓存友好，耗时通常
- 真正代价是失去内联带来的连锁优化：逃逸分析失效、标量替换受阻、循环展开受限
- 常见诱因：泛型擦除后类型信息丢失、反射调用、ASM动态生成类、未预热的测试代码
验证与调优：别猜，用工具看真实行为
是否被优化，源码和字节码无法说明，必须依赖JVM运行时反馈。
- 加参数启动：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation - 日志里搜
inline：看到reason: monomorphic或reason: type check fails就能确认决策依据 - 用
jstack -l <pid></pid>检查栈帧：出现Compiled frame表示已JIT编译，Interpreted frame说明还没热起来 - 简单压测对比：循环调用10万次，对比虚方法与final版本，差异显著超出±5%，大概率是GC、未预热或别的瓶颈
