Java多态性是设计选择而非语法糖，仅当编译时类型与运行时类型不一致且存在继承/实现关系时生效；override方法参与运行时动态绑定，overload则在编译期静态解析。
Java多态性不是语法糖，而是设计选择——它只在**编译时类型和运行时类型不一致**且满足继承/实现关系时才生效；否则哪怕写了 Parent p = new Child()，也不会触发多态行为。
为什么 override 的方法才参与多态，而 overload 不参与
多态绑定发生在运行时（动态绑定），只针对被子类重写（@Override）的实例方法。重载（overload）是编译期根据参数类型静态决定调用哪个方法，跟对象实际类型无关。
常见错误现象：
- 父类有
void print(String s)，子类加了void print(Object o)，以为能多态调用——实际调用取决于变量声明类型（Parent p会走String版本，哪怕指向Child实例） - 把
static方法或private方法当成可多态的方法——它们都绑定在编译时类型上
实操建议：
- 确认方法是否被
@Override标注（IDE 通常会报错提示未正确重写） - 避免在重载方法中依赖运行时类型做逻辑分支，这容易和多态语义混淆
- 用
javap -c查看字节码，观察invokevirtual（多态） vsinvokestatic/invokespecial（非多态）指令
instanceof + 强制转型不是多态，而是对多态失效的补救
当你写 if (obj instanceof Dog) { ((Dog)obj).bark(); }，说明你已经放弃了多态的设计意图——本该由 JVM 自动分派的方法调用，被你手动拆解成了类型判断+转型+调用。
使用场景：
- 需要访问子类特有成员（如
Dog独有的collarColor字段） - 对接遗留代码或泛型擦除后无法保留类型信息的 API
但要注意：
- 每次
instanceof都伴随一次运行时类型检查，频繁使用影响性能（尤其在循环内） - 转型失败抛
ClassCastException，而多态调用永远不会因类型问题崩溃 - 更好的替代：用
Visitor模式、策略接口提取行为，或 Java 14+ 的switch表达式配合模式匹配（case Dog d -> d.bark()）
接口引用多态比抽象类更安全、更灵活
用 List 是典型接口多态；相比 AbstractList，前者完全屏蔽了具体实现细节，也避免了误调用抽象
参数差异：
- 接口只能定义
public abstract方法（Java 8+ 允许default和static） - 抽象类可含
protected方法、构造器、字段，但也意味着更多耦合风险
性能与兼容性影响：
- 接口多态在 JVM 层使用
invokeinterface指令，现代 JIT 已优化到几乎无差别 - 接口更适合组合扩展（一个类可实现多个接口），抽象类仅支持单继承
- 添加新
default方法不会破坏二进制兼容性；但抽象类新增非abstract方法会强制所有子类重新编译
泛型擦除后，多态和类型安全如何共存
Java 泛型在运行时不存在，List 和 List 编译后都是 List。这意味着你不能靠泛型参数做多态分派，比如：
void handle(Listls) { ... } void handle(List li) { ... } // 编译失败：签名重复
所以常见做法是：
- 用泛型限定（
T的方法 - 避免在泛型方法里做
instanceof判断原始类型（list instanceof ArrayList可行，但list instanceof ArrayList编译不过） - 若真需类型区分，把类型信息作为参数传入（
handle(list, String.class)），或用TypeReference（Jackson/Gson 场景）
最容易被忽略的一点：泛型类内部的多态行为，和其类型参数无关——new ArrayList 和 new ArrayList 在运行时都是 ArrayList 实例，它们的 add()、size() 等方法行为完全一致，多态只作用于继承体系，不作用于类型参数。
