抽象类不能实例化是编译期语义限制，由abstract关键字触发，与构造方法访问修饰符无关；其构造方法仅服务于子类初始化，需通过super()显式或隐式调用。

Java 抽象类不能通过 new 关键字实例化，根本原因不是靠构造方法的访问修饰符（比如 protected 或 private），而是由 abstract 关键字触发的编译期语义限制——只要类声明为 abstract，无论构造方法是 public、protected 还是缺省，编译器都会直接报错：“Cannot instantiate the type Xxx”。

抽象关键字才是真正的“开关”

Java 编译器在语法分析阶段就识别出 abstract 类，并禁止生成其对象创建指令。这不是运行时检查，也不是靠反射或 JVM 字节码验证拦截，而是编译失败：

• new Animal() → 编译报错，哪怕 Animal 的构造方法是 public Animal() { }
• 即使抽象类没有任何抽象方法，仅靠 abstract class Foo { } 声明，也无法实例化
• 接口同理，new List() 同样编译不通过（接口更严格，连构造方法都没有）

构造方法的作用不是“放行/拦截 new”，而是服务子类

抽象类可以（也常常需要）定义构造方法，但它的目标用户是子类，不是外部调用者：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 子类构造器中必须通过 super(...) 调用父类构造逻辑（显式或隐式）
• 如果抽象类只提供带参构造（如 protected Person(String name)），子类就必须写 super(name)，否则编译失败
• 构造体里可做参数校验、字段初始化、资源预加载等，和普通类完全一致

为什么别用 public 构造方法？

虽然 public 构造方法不影响“不可实例化”这一事实，但它会误导协作开发者：

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

• 其他程序员可能误以为这个类设计为“可被友好调用”，甚至尝试在同包内 new（尽管编译仍失败）
• IDE 和静态分析工具（如 SonarQube）通常会警告：抽象类不应暴露 public 构造器
• 设为 protected 更准确表达设计意图：仅允许继承链上的子类参与初始化

常见踩坑场景与应对

这类限制在动态场景中容易被绕过语义检查，导致运行时报 InstantiationException：

• 反射创建：如 Class.forName("MyAbstractService").getDeclaredConstructor().newInstance() → 运行时报错
• 框架自动装配：Spring 的 @Bean 方法返回 new AbstractHandler()，启动失败
• JSON 反序列化：Jackson 配置 @JsonDeserialize(as = MyAbstract.class) → 反序列化时抛异常
• 解决办法统一：不用抽象类或接口作为目标类型，改用具体子类；或提前校验 Modifier.isAbstract(cls) || cls.isInterface()