抽象类构造方法中调用抽象方法极危险，因子类重写逻辑会在父类字段未初始化时执行，导致空指针、this逃逸及线程安全问题；应改用模板方法+显式初始化、参数注入或构建器模式规避。
抽象类构造方法中调用抽象方法，是 Java 中一个隐蔽但高危的设计陷阱——它不会编译报错，却极易导致 this 逃逸 和 字段未初始化，引发空指针、状态不一致甚至线程安全问题。
为什么构造器里调用抽象方法很危险
抽象类自身不能实例化，但它的构造器会在子类构造时执行。此时对象尚未构造完成，而抽象方法由子类实现，意味着：子类重写的逻辑会在父类字段还没初始化完毕时就被触发。
- 子类方法中若访问了自己声明的字段（如
config、service），这些字段可能仍是null或默认值 - 若子类实现里启动线程、注册监听器、存入静态容器，就等于把“半成品对象”暴露给了外部，造成 this 逃逸
- 编译器无法检查这种风险，运行时才暴露，且错误位置常指向子类代码，排查困难
典型危险写法示例
以下代码看似合理，实则隐患重重：
abstract class BaseTask {
protected final String taskId;
BaseTask() {
this.taskId = UUID.randomUUID().toString();
init(); // ← 危险！调用抽象方法
}
protected abstract void init();
}
class EmailTask extends BaseTask {
private EmailService emailService; // 还没初始化！
@Override
protected void init() {
// 此时 emailService 是 null
emailService.sendWelcome(); // 空指针异常
// 更糟的是：new Thread(() -> this.process()).start(); ← this 已逃逸
}
}
安全替代方案
核心原则：**构造器只做确定性、无依赖、不涉及子类逻辑的初始化；把可变行为推迟到对象完全构造之后。**
立即学习“Java免费学习笔记（深入）”；
-
改用模板方法 + 显式初始化调用：把
init()拆成两步——父类提供空壳，子类在super()后主动调用 - 强制参数注入：将依赖项（如配置、服务）通过构造参数传入，避免子类自行创建未初始化对象
-
用 final 字段 + 构造参数兜底：关键字段声明为
final，并在构造器中通过参数或安全默认值赋值 - 引入构建器模式：把对象创建与初始化分离，确保所有必要状态就绪后再触发业务逻辑
如何快速识别和修复
审查现有抽象类时，重点关注构造器中所有非 private、非 final 的方法调用：
- 标记出每个被调用的方法，确认它是否是
abstract或可被子类override - 逐个查看子类实现，检查是否包含：
new Thread、executor.submit、staticMap.put(this, ...)、addListener(this)等发布动作 - 对 lambda 或匿名内部类中出现的
this，确认其是否指向正在构造的实例 - 添加单元测试：验证子类构造完成后，所有继承字段是否已正确赋值、无
null
