Java多态运行时绑定开销在绝大多数场景中可忽略，JIT通过去虚拟化和内联优化为直接调用；仅当接口实现爆炸、反射调用、invokedynamic不稳定或低频路径时，才残留1–3纳秒开销。
Java 中多态实现运行时绑定的性能开销在绝大多数实际场景中可以忽略不计。HotSpot JVM 的 JIT 编译器会主动优化虚方法调用，真正残留的开销仅出现在少数边界条件下。
虚方法调用的基础开销来源
未优化时，invokevirtual 或 invokeinterface 指令需执行三步操作：
- 读取对象头中的 klass 指针
- 根据方法槽位偏移查该类的 vtable（或接口的 itable）
- 执行间接跳转（indirect call），可能干扰 CPU 分支预测
这套流程比直接调用多出约 1–3 纳秒，但这是理论峰值，不是常态。
JIT 通常会彻底消除这部分开销
只要满足以下常见条件，JIT 就会在编译后将多态调用优化为直接调用甚至内联：
立即学习“Java免费学习笔记（深入）”；
- 调用点足够热（默认触发 C2 编译约 10000 次）
- 接收者类型稳定（例如 Spring 注入的 Service 始终是同一个实现类）
- 没有禁用类型推测（如未设置 -XX:-UseTypeSpeculation）
此时生成的机器码里没有查表逻辑，也没有间接跳转，性能与静态调用一致。
真正可能保留开销的典型场景
以下情况 JIT 难以做单态优化，虚调用开销可能实际存在：
- 一个接口有数十个 SPI 实现（如自定义 ServiceLoader 插件体系），类型不可预测
- 使用反射（Method.invoke()）或 VarHandle 动态访问，绕过 JIT 类型分析
- invokedynamic 引导不稳定（Groovy/Scala 动态分派中 CallSite 频繁变更）
- 调用发生在低频路径上（如异常分支、GC 安全点附近），JIT 主动放弃优化
如何验证你的多态是否已被优化
不要凭经验猜测，用 JVM 自带工具实测：
- 加参数 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 启动，观察日志中是否出现 inline (hot)
- 用 async-profiler 查看热点方法是否已编译为本地码，并检查调用指令是否为 call 而非 call *reg
- 简单对比：把接口调用换成具体实现类直调，若性能无变化，说明原多态已被优化
