构造函数中启动线程危险，因this引用可能逸出，导致其他线程看到半初始化对象，引发NullPointerException或逻辑错误；应将线程启动移至工厂方法或init()中确保安全发布。
构造函数里启动线程为什么危险
因为对象可能还没初始化完，就被其他线程看到并使用了——这叫“逸出”。this 引用在构造过程中逃出了当前线程的控制范围，别的线程拿到的可能是半初始化的对象。
常见错误现象：NullPointerException、字段为默认值（如 0 或 null）、逻辑错乱但不报错；尤其在多核 CPU 上更容易复现，单线程测试常侥幸通过。
- 不要在构造函数中调用
new Thread(this)::start、executor.submit(this)或任何会暴露this的操作 - 如果必须异步初始化，把线程启动逻辑移到工厂方法或独立的
init()中，确保构造完成后再发布 - 注意匿名内部类和 lambda 表达式：它们隐式持有外部类引用，
new Thread(() -> doWork())同样会逸出this
什么是安全的对象发布
安全发布 = 对象构造完毕后，才让其他线程能访问到它。核心是保证“初始化完成”和“可见性”两个条件同时满足。
常用手段有：static final 字段、volatile 引用、正确加锁的工厂方法、java.util.concurrent 里的线程安全容器（如 ConcurrentHashMap）。
立即学习“Java免费学习笔记（深入）”；
-
static final是最简单的安全发布方式：JVM 保证 final 字段在构造结束前已写入，且对所有线程立即可见 - 用
volatile发布非 final 对象也行，但得确保构造过程本身是线程安全的（比如只在单线程里构造） - 别依赖
synchronized块来“保护构造过程”——锁在构造函数里没意义，此时对象还没建好，锁对象都不可靠
为什么 final 字段能防止逸出问题
final 字段的语义不只是“不可变”，更是 JVM 内存模型里的一个安全栅栏：只要对象是通过正确方式发布的，所有线程看到的 final 字段一定是构造函数里赋的值，不会看到默认值。
但这个保障有个前提：构造函数不能泄露 this。一旦泄露，final 字段的初始化顺序就可能被绕过。
- 哪怕所有字段都是
final，只要构造函数里调用了registerListener(this)这类方法，就可能被监听器立刻调用对象方法，此时 final 字段可能还未赋值 - 子类构造器执行前，父类构造器先跑；如果父类构造器就泄露了
this，子类的 final 字段根本没机会初始化 - IDEA 或 CheckStyle 的
ctor-escape检查就是盯这个点，不是过度约束，是真会出事
替代方案：怎么既异步又不逸出
想让对象创建后自动开始工作？别在构造函数里动手脚，换种发布节奏。
典型做法是分离“构建”和“启动”：先 new 出对象，再由外部明确触发运行逻辑。
- 用静态工厂方法封装：例如
MyService.createAndStart()，内部先new MyService()，再调用service.start() - 实现
AutoCloseable或自定义生命周期接口（如LifeCycle），由容器或调用方统一管理启停 - 如果必须延迟启动，用
ExecutorService.schedule(..., 0, TimeUnit.NANOSECONDS)替代直接start()，至少把执行时机推到构造之后的某个调度点
真正难的不是写对代码，而是意识到“对象刚 new 出来那几毫秒”在并发下根本不属于你——它随时可能被别的线程截胡。这点稍一松懈，bug 就藏进日志深处，等上线才露头。
