多态通过面向抽象编程和动态分派降低耦合：调用方依赖接口/父类而不关心具体实现，新增子类无需修改原有代码；JVM基于实际对象类型查虚方法表执行重写方法，静态/私有/final方法不参与动态分派。
多态通过让调用方只依赖抽象（如接口或父类），不关心具体实现，天然降低了模块间的耦合度；而Java的动态分派机制，正是支撑这种“运行时决定调用哪个方法”的底层保障。
多态如何削弱代码耦合
耦合的本质，是模块之间对彼此细节的强依赖。多态把“用什么”和“怎么用”分开：
- 调用方只面向接口或抽象类编程，不写死具体类型，比如List list = new ArrayList();，后续换成LinkedList完全不用改调用逻辑
- 新增子类无需修改已有调用代码，只要它实现了约定的方法签名，就能被原逻辑无缝接纳
- 测试更简单——可以用模拟对象（Mock）替代真实实现，隔离依赖
动态分派是多态落地的关键机制
Java在运行期根据实际对象类型，而非引用类型，来选择执行哪个重写方法。这个过程叫动态分派，由JVM通过虚方法表（vtable）实现：
- 每个类加载时，JVM为其生成一张虚方法表，记录所有可被重写的方法及其实际入口地址
- 当执行obj.method()时，JVM查obj实际指向的对象所属类的vtable，跳转到对应方法体
- 静态方法、private方法、final方法不参与动态分派，因为它们无法被重写
一个典型例子看清楚流程
假设有Animal抽象类和Dog、Cat两个子类，都重写了makeSound()：
立即学习“Java免费学习笔记（深入）”；
Animal a1 = new Dog(); Animal a2 = new Cat(); a1.makeSound(); // 运行时查Dog的vtable，调用Dog::makeSound a2.makeSound(); // 运行时查Cat的vtable，调用Cat::makeSound
注意：编译期只检查Animal中是否存在makeSound()（静态绑定），真正调哪段代码，留到运行期决定。
避免误用导致耦合反弹
多态不是万能的，用错反而增加隐性耦合：
- 滥用instanceof或强制转型（(Dog) obj），等于又把具体类型暴露给了调用方，破坏了抽象层
- 在父类里大量添加“为某个子类服务”的方法，导致父类膨胀、职责不清
- 过度设计抽象——没有变化点也硬抽接口，反而让代码更难理解
基本上就这些。多态本身不复杂，但动态分派的时机和限制容易忽略，理清它，才能写出真正松耦合、易扩展的代码。
