抽象类必须用abstract声明且不可实例化,是不完整的设计蓝图;可含具体方法、字段和构造器,但构造器不能为private;子类须实现全部抽象方法或自身声明为abstract。

抽象类必须用 abstract 关键字声明,且不能直接实例化
Java 中的抽象类本质是“不完整的设计蓝图”,编译器强制要求用 abstract 修饰类名,否则即使含抽象方法也会报错。试图用 new AbstractClass() 创建对象会触发编译错误:Cannot instantiate the type AbstractClass。
- 抽象类可以包含具体方法、字段、构造器(供子类调用),但构造器本身不能是
abstract - 子类继承抽象类时,必须实现所有未实现的抽象方法,除非子类也声明为
abstract - 抽象类可有
public、protected、包私有构造器,但不能是private(否则子类无法调用)
抽象方法只能出现在抽象类或接口中,且不能有方法体
抽象方法是仅声明、无实现的契约,语法上以分号结尾,不写花括号。它必须定义在 abstract 类或 interface 中;若出现在普通类里,编译直接失败:Abstract method in non-abstract class。
- 抽象方法默认是
public abstract,不能加private、static、final、synchronized等修饰符 - 抽象类中可以同时存在抽象方法和具体方法,比如模板方法模式常用:抽象方法定义步骤,具体方法封装流程控制
- 注意:
static方法不能是抽象的,因为静态绑定与抽象的“运行时多态”目标冲突
抽象类 vs 接口:选择取决于是否需要共享状态或构造逻辑
抽象类适合表达“是什么”(is-a 关系)并复用代码;接口更适合定义“能做什么”(can-do 能力)。Java 8+ 后接口也能有默认方法,但关键差异仍在:
- 抽象类可含实例字段(如
protected String name)、构造器、静态代码块,接口不能 - 一个类只能继承一个抽象类,但可实现多个接口——这是 Java 单继承限制下的核心权衡点
- 如果需要初始化共享资源(如数据库连接池配置)、提供部分实现、或强制子类共用父类生命周期逻辑,优先选抽象类
常见误用:把工具类或常量容器错误设计成抽象类
比如有人为避免实例化而将纯静态工具类声明为 abstract class StringUtils,这属于反模式。JVM 不阻止你这么做,但语义错位,且容易误导后续维护者以为该类需被继承。
立即学习“Java免费学习笔记(深入)”;
- 纯静态方法集合应使用
final class+ 私有构造器(如private StringUtils() {}) - 抽象类一旦被继承,就隐含了“行为扩展”的契约;若子类只为了调用几个静态方法,说明设计偏离初衷
- IDE 和静态分析工具(如 SonarQube)通常会标记这种抽象类为 “Class has no abstract methods but is declared abstract” 警告
abstract class Animal {
protected String name;
// 共享构造逻辑
protected Animal(String name) {
this.name = name;
}
// 抽象方法:子类必须实现
public abstract void makeSound();
// 具体方法:可直接复用
public void sleep() {
System.out.println(name + " is sleeping");
}
}
class Dog extends Animal {
public Dog(String name) {
super(name); // 必须调用父类构造器
}
@Override
public void makeSound() {
System.out.println(name + " barks");
}
}
抽象类的真正复杂点不在语法,而在建模边界——它既不是接口那样的纯粹契约,也不是普通类那样的完整实现。什么时候该抽出公共字段?要不要暴露受保护的构造器?子类是否真的需要共享状态而非仅行为?这些判断比写 abstract 关键字难得多。










