构造方法中启动线程不安全，因this指针可能逸出，导致其他线程看到未初始化对象；jvm重排序使字段赋值不可见，且无happens-before保证；应避免构造中启线程，改用显式init或工厂模式。
构造方法中启动线程是不安全的，核心问题在于this指针可能在对象尚未完全初始化时就被其他线程访问，这违反了Java内存模型（JMM）对安全发布的基本要求。
构造过程中 this 会“逸出”
当在构造函数里创建并启动新线程，并把 this 作为参数传入 Runnable 或 Thread 构造器时，相当于把一个正在构建中的对象暴露给了另一个线程。此时该对象的字段可能还未完成赋值（即使代码写在 start() 前），因为：
- JVM 允许指令重排序，只要不改变单线程语义；
this的发布动作可能被提前到字段初始化之前 - 新线程看到的可能是部分初始化、甚至全为默认值（如
int为 0、引用为null）的对象状态 - 即使字段赋值写在
start()前，也不构成对其他线程的“happens-before”关系，无法保证可见性
没有 happens-before 保证
Java 内存模型规定：只有明确建立 happens-before 关系，才能确保一个线程对变量的修改对另一线程可见。而构造函数内启动线程，主线程和新线程之间不存在天然的同步点：
-
thread.start()不同步于新线程的run()开始执行 - 构造函数结束、对象“看起来已建好”，不等于其状态对其他线程可见
- 新线程可能读到未初始化字段、看到空引用、或调用尚未准备就绪的方法
典型风险表现
常见后果不是立即崩溃，而是隐蔽的、偶发的错误：
- 字段值为默认值（如期望 10 却读到 0）
- 调用尚未初始化的依赖对象，抛出
NullPointerException - 对象处于不一致状态（例如配置未加载完，但线程已开始处理任务）
- 难以复现和调试——只在特定 CPU 架构、JVM 版本或高负载下触发
安全替代方案
避免在构造函数中启动线程，改用显式初始化流程：
- 构造函数只做字段赋值和基本校验，返回一个“半成品”对象
- 由外部调用方负责调用
init()或start()方法，在对象完全构造后再启动线程 - 使用工厂方法或构建器模式，将对象创建与线程启动分离
- 若必须内部管理生命周期，可考虑延迟初始化（如通过
ExecutorService提交任务，而非直接new Thread().start()）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
