Java里的抽象方法必须被重写吗_子类实现规则与编译约束

抽象方法在非抽象子类里必须重写

是的，只要子类不是 abstract 类，它就必须实现父类中所有未实现的抽象方法。Java 编译器会强制检查这一点，不满足就直接报错。

常见错误现象：java: method does not override or implement a method from a supertype（当用了 @Override 但父类没对应抽象方法），或者更典型的：java: xxx is not abstract and does not override abstract method yyy() in ZZZ —— 这说明你写了个具体类，却漏了某个抽象方法的实现。

• 如果子类也声明为 abstract，那它可以不实现父类的抽象方法，但继承链上最终得有非抽象子类来落实
• 重写时方法签名（名称、参数类型、顺序）必须完全一致；返回类型可以是原类型的子类型（协变返回）
• 访问修饰符不能比父类抽象方法更严格（比如父类是 public，子类不能写 protected）

接口里的 default 方法和抽象方法混用时要注意什么

接口从 Java 8 开始支持 default 方法，它们不是抽象的，子类（包括实现类）可选重写。但如果你同时定义了抽象方法，规则没变：抽象方法仍需被实现，default 方法则不用。

使用场景：给老接口扩展功能又不破坏已有实现类，就加 default；需要强制子类提供差异化逻辑的地方，继续用抽象方法。

立即学习“Java免费学习笔记（深入）”；

Seed-Music

字节跳动推出的AI音乐生成与编辑工具

下载

• 一个类同时继承抽象类又实现接口，且两者都有同名抽象方法 → 必须在该类中显式实现一次，不能靠接口的 default “抵消”抽象类的要求
• 若接口 A 和 B 都提供了同名同签名的 default 方法，实现类必须覆写该方法，否则编译失败
• default 方法不能访问实现类的私有成员或 this 的非 public 字段，作用域仅限于接口自身

泛型抽象类中抽象方法的类型擦除影响

泛型信息在运行时被擦除，但编译期仍按泛型约束检查重写正确性。这意味着子类重写抽象方法时，不能只靠返回值类型不同来构成重载，更不能绕过泛型边界。

例如，父类定义 abstract <T extends Number> T getValue();，子类实现时不能写成 Integer getValue() 就完事——虽然 Integer 是 Number 子类，但方法签名中的类型变量 T 仍需匹配约束逻辑；更稳妥的是直接指定具体类型，如 @Override Integer getValue()（前提是父类允许协变）。

• 抽象方法带泛型参数时，子类实现必须保持形参类型可兼容，比如父类是 <E> void add(E item)，子类可写 void add(String item)，但不能再加新类型参数
• 类型擦除后，JVM 看不到泛型，所以反射获取方法签名会显示 Object 或原始类型，别依赖运行时泛型做逻辑分支
• IDE 可能提示“method does not override”，其实是泛型推导失败，检查子类方法是否意外引入了新类型变量，或边界不匹配

抽象方法抛出异常时子类重写的限制

子类重写抽象方法时，可以缩小甚至去掉 throws 子句，但不能扩大异常范围。这是为了保证多态调用的安全性：父类声明可能抛 IOException，子类实际只抛 FileNotFoundException（它是 IOException 子类）可以；反过来就不行。

容易踩的坑是误以为“不写 throws 就等于没异常”，其实如果父类抽象方法声明了受检异常（checked exception），子类实现里哪怕逻辑上不会抛，也必须处理它——要么 try-catch，要么在方法签名中继续声明（可以是相同或更具体的异常）。

• 运行时异常（RuntimeException 及其子类）不受此限制，子类可自由增删 throws
• 如果父类抽象方法没声明任何受检异常，子类实现里就不能新增受检异常声明，否则编译失败
• 构造器、静态方法不能被重写，所以抽象类里的抽象构造器或 static 抽象方法本身就不合法，Java 不允许