为什么不应该在类的构造函数中使用Thread.start（）？

为什么不应该在类的构造函数中使用Thread.start（）？

但是对象已被完全构造，构造函数只剩下返回即可

是的，没有。问题在于，根据Java内存模型，编译器能够对构造函数进行 重新排序 ，并在构造函数完成 后 实际完成对象的构造函数。

volatile

或 将 确保在构造函数完成之前初始化

final

字段，但不能保证（例如）在构造函数完成之前正确初始化您的字段。
__

importantData data

但是，
正如@meriton在注释中指出的那样，在与线程和启动该线程的线程之间发生联系之前会发生一种情况。在＃2的情况下，您很好，因为

data

必须在启动线程之前完全分配该线程。根据Java内存模型可以保证这一点。

也就是说，在其构造函数中将对某个对象的引用“泄漏”到另一个线程是不明智的做法，因为如果在线程 之后
添加了任何构造函数行，

t.start()

则该线程将看到对象是否已完全构造成竞争状态。

这里有更多阅读内容：

• Doug Lea的内存模型页面讨论了指令重新排序和构造函数。
• 这是有关安全的构造函数实践的重要内容，其中更多地讨论了这一点。
• 这就是为什么“双重检查锁定”问题也存在问题的原因。