链接构造函数时，JVM 的隐式内存屏障如何表现？

Question

参考我的之前关于不完全构造对象的问题，我有第二个问题。正如 Jon Skeet 指出的那样，构造函数末尾有一个隐式内存屏障，可确保 final 字段对所有线程都可见。但是如果一个构造函数调用另一个构造函数怎么办？它们每个的末尾都存在这样的内存障碍，还是仅在第一个被调用的那个的末尾存在这样的内存障碍？也就是说，当“错误”的解决方案是：

public class ThisEscape {
    public ThisEscape(EventSource source) {
        source.registerListener(
            new EventListener() {
                public void onEvent(Event e) {
                    doSomething(e);
                }
            });
    }
}

正确的解决方案是工厂方法版本：

public class SafeListener {
    private final EventListener listener;

    private SafeListener() {
        listener = new EventListener() {
            public void onEvent(Event e) {
                doSomething(e);
            }
        }
    }

    public static SafeListener newInstance(EventSource source) {
        SafeListener safe = new SafeListener();
        source.registerListener(safe.listener);
        return safe;
    }
}

以下内容是否也有效？

public class MyListener {
    private final EventListener listener;

    private MyListener() {
        listener = new EventListener() {
            public void onEvent(Event e) {
                doSomething(e);
            }
        }
    }

    public MyListener(EventSource source) {
        this();
        source.register(listener);
    }
}

更新：最根本的问题是，this() 是否能保证实际调用上面的私有构造函数（在这种情况下，就会存在以下障碍：预期的并且一切都会安全），或者私有构造函数是否有可能内联到公共构造函数中，作为一种优化来节省一个内存屏障（在这种情况下，直到公共构造函数的末尾）？

this() 的规则是否在某处精确定义？如果没有，那么我认为我们必须假设内联链式构造函数是允许的，并且可能某些 JVM 甚至 javac 正在这样做。

Answer 1

我认为它是安全的，因为 java 内存模型指出：

令o为一个对象，c为o的构造函数，其中最终
字段f被写入。对 o 的最后一个字段 f 执行冻结操作
当 c 正常或突然退出时。请注意，如果一个
构造函数调用另一个构造函数，并且被调用的构造函数
设置最后一个字段，最后一个字段的冻结发生在
调用的构造函数结束。

Answer 2

当对象的构造函数完成时，该对象被认为已完全初始化。

这也适用于链式构造函数。

如果必须在构造函数中注册，请将侦听器定义为静态内部类。这是安全的。

Answer 3

您的第二个版本不正确，因为它允许“this”引用从构造过程中逃脱。 'this' 转义会使赋予最终字段安全性的初始化安全保证失效。

为了解决隐含的问题，构造结束时的障碍仅发生在对象构造的最后阶段。一位读者提供的关于内联的直觉是很有用的；从Java内存模型的角度来看，方法边界不存在。

Answer 4

编辑 在建议编译器内联私有构造函数的评论之后（我没有想到这种优化），代码很可能是不安全的。不安全的多线程代码最糟糕的部分是它似乎可以工作，所以你最好完全避免它。如果您想玩不同的技巧（由于某种原因您确实想避免使用工厂），请考虑添加一个包装器以保证内部实现对象中的数据和外部对象中的注册数据的一致性。

---

我的猜测是它会很脆弱但还好。编译器无法知道内部构造函数是否仅从其他构造函数内部调用，因此它必须确保仅调用内部构造函数的代码结果是正确的，因此无论它使用什么机制（内存屏障？）在那里就位。

我猜测编译器会在每个构造函数的末尾添加内存屏障。问题仍然存在：在完全构造之前，您将 this 引用传递给其他代码（可能是其他线程）——这很糟糕——，但是如果剩下唯一的“构造”正在注册侦听器，那么对象状态将一如既往地稳定。

解决方案是脆弱，因为有一天，您或其他程序员可能需要向对象添加另一个成员，并且可能会忘记链式构造函数是一个并发技巧，并且可能决定在公共构造函数，这样做会在应用程序中添加难以检测的潜在数据竞争，因此我会尽力避免该构造。

顺便说一句：猜测的安全性可能是错误的。我不知道编译器有多复杂/智能，也不知道内存屏障（或类似的）是否可以尝试优化掉......因为构造函数是私有的，所以编译器确实有足够的信息来知道它是仅从其他构造函数调用，这足以确定内部构造函数中不需要同步机制......

Answer 5

在 c-tor 中转义对象引用可以发布不完整构造的对象。即使发布是构造函数中的最后一个语句，情况也是如此。

即使执行了 c-tor 内联，您的 SafeListener 在并发环境中也可能表现不佳（我认为不是 - 考虑通过访问私有 c-tor 使用反射创建对象）。