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

Question

我一直在寻找为什么不应该在类的构造函数中调用线程的start方法的理由。考虑以下代码：

class SomeClass
{
    public ImportantData data = null;
    public Thread t = null;

    public SomeClass(ImportantData d)
    {
        t = new MyOperationThread();

        // t.start(); // Footnote 1

        data = d;

        t.start();    // Footnote 2
    }
}

ImportantData是一些通用的东西（可能很重要），而MyOperationThread是知道如何处理SomeClass实例的线程的子类。

脚节点：

1. 我完全理解为什么这是不安全的。如果MyOperationThread在以下语句完成（并且数据已初始化）之前尝试访问SomeClass.data，我将得到一个异常，我本来没有做好准备。也许我不会。您不能总是通过线程来区分。无论如何，以后我都会为怪异的意外行为做好准备。

2. 我不明白为什么这样做是禁地。至此，所有SomeClass的成员都已初始化，没有其他任何更改状态的成员函数被调用，从而有效地完成了构造。

据我了解，这样做被认为是不好的做法，原因是您可以“泄漏对尚未完全构建的对象的引用”。但是对象已被完全构造，构造函数只剩下返回即可。我搜索了其他问题，以寻求对该问题的更具体答案，也研究了参考资料，但是没有发现任何内容“您不应该因为这种不良行为”，而仅发现“你不应该。”

在构造函数中启动线程与这种情况在概念上有何不同：

class SomeClass
{
    public ImportantData data = null;

    public SomeClass(ImportantData d)
    {
        // OtherClass.someExternalOperation(this); // Not a good idea

        data = d;

        OtherClass.someExternalOperation(this);    // Usually accepted as OK
    }
}

另外，如果班级是决赛，该怎么办？

final class SomeClass // like this
{
    ...

我看到了很多有关此问题的问题和您不应该回答的问题，但是没有一个提供了解释，所以我想我想添加一个包含更多细节的问题。

Answer 1

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

是的，没有。问题在于，根据Java内存模型，编译器能够对构造函数进行 重新排序 ，并在构造函数完成 后 实际完成对象的构造函数。
volatile或 将 确保在构造函数完成之前初始化final字段，但不能保证（例如）在构造函数完成之前正确初始化您的字段。
__ImportantData data

但是，
正如@meriton在注释中指出的那样，在与线程和启动该线程的线程之间发生联系之前会发生一种情况。在＃2的情况下，您很好，因为data必须在启动线程之前完全分配该线程。根据Java内存模型可以保证这一点。

也就是说，在其构造函数中将对某个对象的引用“泄漏”到另一个线程是不明智的做法，因为如果在线程 之后
添加了任何构造函数行，t.start()则该线程将看到对象是否已完全构造成竞争状态。

这里有更多阅读内容：

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