Java多态本身不显著影响性能，关键在于JIT是否成功内联：单态场景下JIT会消除动态绑定开销，仅当类型频繁切换或存在反射等误用时才产生可观测性能差异。
Java 中验证多态代码的执行效率与性能，关键不在于“是否用了多态”，而在于确认多态带来的动态绑定开销是否在可接受范围内，并排除误判（比如把编译期优化、JIT 热点编译或测量噪声当成多态瓶颈）。
关注 JVM 运行时行为，而非字节码表象
Java 的多态调用（如 animal.eat()）在字节码中是 invokevirtual 指令。它本身不慢——真正影响性能的是 JVM 如何解析和优化这条指令：
- JVM 启动初期可能做虚方法表（vtable）查表，开销微乎其微（纳秒级）
- 一旦方法被频繁调用，JIT 编译器会进行**单态内联（monomorphic inline）**：如果运行时发现该
invokevirtual总是命中同一个子类（例如 99% 是Dog.eat()），JIT 会直接内联该实现，消除多态开销 - 若类型频繁切换（如
Animal引用轮流指向Dog、Cat、Bird），JIT 可能退化为去优化（deoptimization）或使用更保守的调用方式，此时才可能产生可观测的差异
用 JMH 做可信的微基准测试
避免手写 System.nanoTime() 循环——它无法规避预热、GC 干扰、JIT 预热延迟等问题。正确做法是使用 JMH：
- 定义两个测试方法：一个用多态调用（
Animal a = new Dog(); a.eat();），一个用直接调用（new Dog().eat();） - 确保测试对象创建和调用逻辑对齐（例如都复用同一对象引用，避免构造开销干扰）
- 运行足够长的预热轮次（如
@Fork(warmups = 5)），让 JIT 充分优化 - 观察
score ± error是否有统计显著差异；多数情况下，两者吞吐量（ops/s）几乎一致
检查实际生成的汇编代码（进阶）
当怀疑 JIT 未按预期优化时，可启用 HotSpot 调试标志观察真实执行路径：
- 添加 JVM 参数：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:CompileCommand=print,*Test.testMethod - 查找输出中是否出现
call指令（表示未内联）还是直接展开为子类方法体（表示已内联） - 注意：需安装 hsdis 插件，且仅适用于 Linux/macOS + server VM
警惕真正的性能陷阱，而非多态本身
实践中，拖慢性能的往往不是多态机制，而是伴随多态出现的设计问题：
- 过度抽象：几十个子类共用一个超大接口，每次调用都要查 vtable + 可能的空指针/类型检查
-
反射式多态：用
Class.forName(...).getMethod(...).invoke(...)替代重写，开销比invokevirtual高 2~3 个数量级 -
无意义的向上转型：
Animal a = new Dog(); a = new Cat();频繁切换引用，阻碍 JIT 优化稳定性 -
重写方法体过大：比如在
eat()里做 I/O 或同步块——这时瓶颈在业务逻辑，与多态无关
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
