Java多态性能开销极小，HotSpot JIT通过类型推测和去虚拟化可消除虚调用开销；仅在接口实现过多、反射调用等少数场景残留微小开销（1–3纳秒），远不如设计误用（如滥用instanceof）危害大。
Java 多态本身带来的性能开销极小，现代 JVM（尤其是 HotSpot）在多数场景下能完全消除虚方法调用的开销，不构成是否使用多态的决策依据。
虚方法调用在 JIT 编译后通常被内联或去虚拟化
HotSpot JVM 的 C2 编译器会持续分析运行时类型信息。当某个 invokevirtual 调用的目标类长期稳定（例如 99%+ 都是 ArrayList），JIT 就会将其优化为直接调用，甚至进一步内联方法体。这种优化叫「类型推测（type profiling）」和「去虚拟化（devirtualization）」。
关键前提：
- 该调用点需被频繁执行（进入 C2 编译阈值，默认约 10000 次）
- 实际子类分布不能过于离散（比如始终只有 1–2 种实现，而非每次随机切换）
- 未开启
-XX:-UseTypeSpeculation等禁用推测的选项
你可以用 -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 观察是否出现 inline (hot) 或 already compiled into a big method 等提示。
哪些情况真会残留多态开销？
不是所有多态调用都能被优化掉。以下场景可能保留查虚函数表（vtable）或接口表（itable）的间接跳转：
- 接口方法调用且实现类过多（如自定义 SPI 加载了几十个
ServiceLoader实现） - 反射调用
Method.invoke()或VarHandle动态访问——这类根本绕过 JIT 的类型推测 - 使用
invokedynamic但引导方法返回不稳定 CallSite（如 Groovy/Scala 的动态分派） - 在 GC 安全点附近、或低频路径上（如异常处理分支里的多态调用），JIT 可能放弃优化
此时单次调用开销约增加 1–3 纳秒（相比直接调用），但除非你在 tight loop 里每纳秒都要调用，否则对吞吐或延迟无实质影响。
比性能更值得警惕的是设计误用
开发者常因“怕慢”而回避多态，结果写出一堆 if (obj instanceof X) { ... } else if (obj instanceof Y) { ... }，这反而更糟：
- 逻辑分散，违反开闭原则；新增子类
必须修改所有判断处
- JVM 更难做类型推测（因为分支掩盖了真实调用模式）
- 编译器无法对不同分支做差异化优化（比如某分支适合向量化，另一分支不适合）
真正该权衡的不是“要不要多态”，而是：
- 抽象是否合理？
Shape.draw()合理，User.process()若涵盖注册、扣款、日志等完全不同语义就不合理 - 继承深度是否失控？超过 3 层的类继承链会让 JIT 类型推测失效概率上升
- 是否混淆了“多态”和“泛型”？集合操作优先用
List而非List+ 运行时转型
// ✅ 推荐：清晰抽象，JIT 友好
interface PaymentProcessor {
void charge(BigDecimal amount);
}
class CreditCardProcessor implements PaymentProcessor { ... }
class AlipayProcessor implements PaymentProcessor { ... }
// 使用处
PaymentProcessor p = getProcessor(); // 类型稳定时 JIT 自动优化
p.charge(amount); // 不必担心这行慢
// ❌ 不推荐：手动类型检查，阻碍优化且难维护
Object obj = getPayment();
if (obj instanceof CreditCardProcessor) {
((CreditCardProcessor) obj).charge(amount);
} else if (obj instanceof AlipayProcessor) {
((AlipayProcessor) obj).charge(amount);
}
多态的代价不在字节码或 CPU 指令层面，而在人脑维护成本。只要抽象边界清晰、实现收敛，JVM 会替你扛下性能问题——但如果你为了“避免虚调用”把逻辑写成一长串 instanceof 嵌套，那才是真正拖慢系统的地方。
