Java方法重写与多态详解

大家好，今天本人给大家带来文章《Java方法重写与多态实现详解》，文中内容主要涉及到，如果你对文章方面的知识点感兴趣，那就请各位朋友继续看下去吧~希望能真正帮到你们，谢谢！

Java中多态必须依赖方法重写，子类需用@Override正确重写父类非final/static/private方法，确保签名一致、返回类型协变、访问权限不更严格，否则动态绑定失效。

重写是实现多态的必要条件

Java 中的多态（运行时多态）必须依赖方法重写。没有 @Override 的子类方法，即使签名相同，也不会触发动态绑定；JVM 在运行时只会根据对象实际类型去查找被重写后的方法，而不是声明类型。

常见错误现象：Animal a = new Dog(); a.speak(); 输出的是 Animal 的实现，说明 Dog.speak() 没有正确重写 —— 很可能是参数列表不一致、返回类型不协变，或加了 static/private 修饰符。

• final、static、private 方法不能被重写，也就无法参与多态
• 重写要求子类方法签名（名称 + 参数类型）与父类完全一致，返回类型需是父类返回类型的子类型（协变返回）
• 访问权限不能比父类更严格（如父类 protected，子类不能写 private）

编译期看引用类型，运行期看实际类型

多态行为在编译阶段只检查引用类型是否定义了该方法（即“能不能调”），而真正执行哪个版本，由堆中对象的实际类型决定。这个机制完全依赖 JVM 的虚方法表（vtable）和重写后的入口地址替换。

典型陷阱：List list = new ArrayList(); 中，list.add() 调用的是 ArrayList.add()，不是 List 接口里的默认方法（除非显式调用 List.super.add()）。接口方法默认不是虚方法调用目标，只有被类重写后才进入多态链。

• 接口中的 default 方法不参与子类对父类方法的重写逻辑，它属于“接口继承”，不是“类继承重写”
• 若父类和接口都定义了同名同参方法，且子类未重写，则编译报错（歧义）
• super.method() 是静态绑定，绕过动态分派，不体现多态

重写失败时多态就失效

很多看似“像重写”的写法其实只是重载（overload）或隐藏（hiding），不会触发多态。例如子类写了 toString(String)，而父类是 toString()，这根本不是重写，只是新增了一个重载方法。

容易忽略的兼容性影响：Java 9+ 对 var 类型推导的支持不影响重写判断，但若使用泛型桥接方法（bridge method），编译器自动生成的桥接方法可能掩盖重写失败问题，需用 javap -c 查看字节码确认是否真有 invokespecial 或 invokevirtual。

• 父类方法抛出 IOException，子类重写时只能抛出 IOException 子类或不抛异常；否则编译失败，重写中断
• 泛型擦除后若签名冲突（如 set(List) 和 set(List)），实际都变成 set(List)，会导致重写失败或编译错误
• 使用 Lombok 的 @EqualsAndHashCode 或 @Data 时，若手动写了 equals(Object) 却没按规范处理 null 或类型转换，表面重写成功，实则破坏多态语义

class Animal {
    public void speak() { System.out.println("Animal sound"); }
}
class Dog extends Animal {
    @Override
    public void speak() { System.out.println("Woof!"); }
}
public class Main {
    public static void main(String[] args) {
        Animal a = new Dog(); // 引用类型 Animal，实际类型 Dog
        a.speak(); // 输出 "Woof!" —— 多态生效
    }
}

重写不是语法糖，它是 JVM 动态分派机制的锚点。一旦重写契约被破坏（比如返回类型不协变、异常声明越界、甚至 IDE 自动生成时漏掉 @Override 注解导致隐式重载），多态就会静默退化为单态调用——而这种错误往往在测试覆盖不到的分支里才暴露。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。