java - 可变对象的安全发布

Question

我阅读了几个相关问题，但没有一个解释安全发布持有人的方式。我仍然对 Java 并发实践中的示例感到困惑，第 3.5 节:

有类Holder:

public Holder {
    private int n;
    public Holder(int n) { this.n = n };
    public void assertSanity() {
        if(n != n)
             throw new AssertionError("This statement is false.");
    }
}

及其不安全的出版物:

//unsafe publication
public Holder holder;
    public void initialize() {
        holder = new Holder(42);
    }

可以抛出 AssertionError，我同意。作者写道，这是因为不安全的出版，但另一方面没有答案: 什么是正确的发布方式？ 他们指出了 4 个安全发布习语，但我不明白，为什么他们会在上述情况下工作:

To publish an object safely, both the reference to the object and the object's state must be made visible to other threads at the same time. A properly constructed object can be safely published by:

1. Initializing an object reference from a static initializer;
2. Storing a reference to it into a volatile field or AtomicReference;
3. Storing a reference to it into a final field of a properly constructed object;
4. or Storing a reference to it into a field that is properly guarded by a lock.

我同意 1 和 4，但怀疑以下出版物为何有效:

//safe publication
public volatile Holder holder;

或

//safe publication
public final Holder holder;

volatile 和 final 仅对引用有影响，对引用的对象状态没有影响，所以我认为 AssertionError 仍然是可能的，对吧？

作者展示了如何使持有人对不安全的出版物免疫，而不是出版物的改进，方法是:

private final int n;

我很好奇以下是否也有效？它与(有效的)不变性有何联系？

private volatile int n;

这是我的第一个问题，谢谢你的帮助!

Answer 1

其实我觉得volatile在这里解释起来最简单。 不安全发布发生在可以重新排序操作时，而 volatile 阻止了这种情况。我可以解释更多，但它是 already explained far more accurate than I will do .

基本上在下面将插入适当的内存屏障，以防止重新排序，如 here 所述。 .本质上，volatile 的作用是，如果 ThreadA 读取 ThreadB 执行的 volatile 更新，它保证还可以看到在该 volatile 写入之前完成的所有更新。

final 也使事情变得安全，特别是 written in the JLS .

但是这里有两种情况:将对它的引用存储到正确构造的对象的最终字段中。

所以根据 JLS，这是安全发布:

class Holder {
    private final int n; // making final here
}

顺便说一句，插入了适当的内存屏障，以防止通过发布引用本身对构造函数中的存储进行重新排序。

这个例子呢？

static class Holder {

   private int n;

   public void setN(int n){
      this.n = n;
   }
}

还有别的地方:

 class Other {
    final Holder holder;
    Other(){
        holder = new Holder();
        holder.setN(12);
    }
 }

根据 this 看来这仍然是安全的出版物