Java多态调用在字节码层面确有动态分派开销，但JIT几乎总能通过去虚拟化优化为直接调用甚至内联，日常业务中感知不到性能差异；仅当接口实现爆炸、反射调用、invokedynamic不稳定或低频路径时才可能残留1–3纳秒开销。
Java多态调用本身在字节码层面是虚方法调用（invokevirtual 或 invokeinterface），天然带有动态分派开销，但现代JVM（如HotSpot）的JIT编译器几乎总能将其优化掉——日常业务代码中，你几乎感知不到性能差异。
绝大多数多态调用会被JIT“去虚拟化”
JIT在运行时持续收集类型信息：如果某个虚方法调用点长期只见到一种实际类型（比如 list.add() 总是调用 ArrayList.add()），JIT就会把它当作单态（monomorphic）处理，直接内联目标方法体，彻底消除查表跳转。这个过程叫“去虚拟化”（devirtualization），效果等同于静态调用。
- 触发条件：该调用点被频繁执行（达到C1/C2编译阈值），且接收者类型稳定
- 优化结果：生成的机器码里没有vtable/itable查找，也没有间接跳转
- 典型场景：Spring Bean注入的Service、DAO层接口实现、常用集合操作
真正残留开销的几种情况
不是所有多态都能被优化。以下情形可能保留间接调用开销（约1–3纳秒/次），但仅在极端敏感路径才需关注：
-
接口实现爆炸：一个接口有几十个SPI实现（如自定义
ServiceLoader加载的插件），JIT难以稳定推测类型 - 反射或VarHandle动态访问：绕过JIT类型推断机制，每次都要走通用分派逻辑
- invokedynamic引导不稳定：Groovy/Scala等语言的动态调用，若CallSite频繁变更，内联缓存失效
- 低频或GC安全点附近路径：如异常分支里的多态调用，JIT可能放弃优化以节省编译时间
怎么判断你的多态是否被优化了
不用猜，用JVM自带工具验证：
- 加参数
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining运行程序，观察日志中是否出现inline (hot)或did not inline because: type check fails - 用
jstack -m或async-profiler查看热点方法是否已编译为本地码，并检查调用指令是否为直接call而非间接call - 简单压测对比：把接口调用换成具体实现类直调，性能无明显变化，说明原多态已被优化
写代码时不必为多态性能纠结
设计优先考虑清晰性与可维护性。JIT的优化能力足够强，只要避免刻意制造类型不可预测性（比如在循环里不断 new 不同类的实例再调同一接口），多态带来的开销就远小于一次HashMap扩容、一次字符串拼接或一次不必要的装箱。
真正影响性能的是算法复杂度、内存分配模式和IO等待——而不是多态本身。
