多态性是支撑系统灵活扩展的底层机制，其核心是运行时动态分派：jvm根据对象实际类型查vtable调用具体方法，实现支付、通知等业务的可插拔；静态分派（如重载）仅编译期绑定，不支持运行时替换。
多态性在实际业务中不是抽象概念，而是支撑系统灵活扩展的底层机制。它的核心分派逻辑直接决定了“同一段调用代码”最终执行哪段业务逻辑——这个决策过程发生在运行期，且完全由对象的实际类型驱动。
动态分派是业务可插拔的关键
真实业务里，支付、通知、审批等流程常需支持多种实现（如微信支付/支付宝/银联），而主流程代码不能也不该感知具体实现细节。这时就依赖 JVM 的 动态分派（Dynamic Dispatch）：
- 当调用一个被重写（
@Override）的实例方法时，JVM 使用invokevirtual指令，不看变量声明类型，而是查对象在堆内存中的真实类信息； - 再通过该类的方法表（vtable），定位到实际要执行的方法字节码地址；
- 比如
Payment p = new WechatPayment(); p.pay(100);，哪怕p是Payment接口类型，JVM 仍会调用WechatPayment.pay()。
静态分派只管“编译时能看见什么”
它发生在编译阶段，和业务扩展关系不大，但容易混淆：
- 方法重载（Overloading）就是典型静态分派：编译器根据参数的静态类型和数量选方法，比如
log(String)和log(Exception)； - 这种选择在 class 文件里就固定了，运行时不会变；
- 业务中若误把重载当重写用（例如想靠参数类型切换策略），会导致行为不符合预期——因为这不是多态，不支持运行时替换。
接口与抽象类让分派更干净
面向接口编程本质是把动态分派的入口标准化：
- 接口定义契约（如
OrderProcessor.process()），所有实现类必须提供具体逻辑； - 业务模块（如订单服务）只依赖接口，不依赖任何实现类，新增一种处理方式只需加个新实现类 + 配置注入；
- JVM 对
invokeinterface同样做动态分派：运行时查对象实际类，再找该类对接口方法的具体实现，效率略低于invokevirtual，但语义更清晰、耦合更低。
哪些情况会“绕开”动态分派？
这些是业务中容易踩坑的地方，它们不参与多态分派：
-
static 方法：绑定到类，不是对象，调用看引用类型，
Parent.method()永远执行父类逻辑； - private / final 方法：编译期直接内联或绑定，子类无法覆盖，也就没有运行时选择；
-
成员变量访问：字段不具多态性，
parent.field取的是Parent类定义的字段值，哪怕对象是子类实例； - 构造方法：只属于当前类，不存在“被子类多态调用”的概念。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
