java - volatile 发布保证有多深？

Question

众所周知，如果我们有一些对象引用并且这个引用有 final 字段 - 我们将从 final 字段看到所有可到达的字段(至少在构造函数完成时)

例子1:

class Foo{
    private final Map map;
     Foo(){
         map = new HashMap();
         map.put(1,"object");
     }

     public void bar(){
       System.out.println(map.get(1));
     }
}

据我了解，在这种情况下，我们可以保证 bar() 方法始终输出 object，因为:
1. 我列出了 Foo 类的完整代码， map 是最终的；
<强>2。如果某个线程将看到 Foo 的引用并且此引用 != null，那么我们可以保证从最终 map 引用值可达的值将是实际的。。

我也觉得

例子2:

class Foo {
    private final Map map;
    private Map nonFinalMap;

    Foo() {
        nonFinalMap = new HashMap();
        nonFinalMap.put(2, "ololo");
        map = new HashMap();
        map.put(1, "object");
    }

    public void bar() {
        System.out.println(map.get(1));
    }

    public void bar2() {
        System.out.println(nonFinalMap.get(2));
    }
}

这里我们对 bar() 方法有相同的保证，但是 bar2 可以抛出 NullPointerException 尽管发生了 nonFinalMap 赋值在 map 赋值之前。

我想知道 volatile 怎么样:

示例 3:

class Foo{
        private volatile Map map;
         Foo(){
             map = new HashMap();
             map.put(1,"object");
         }

         public void bar(){
           System.out.println(map.get(1));
         }
    }

据我所知，bar() 方法不能抛出 NullPoinerException 但它可以打印 null； (我完全不确定这方面)

示例 4:

class Foo {
    private volatile Map map;
    private Map nonVolatileMap;

    Foo() {
        nonVolatileMap= new HashMap();
        nonVolatileMap.put(2, "ololo");
        map = new HashMap();
        map.put(1, "object");
    }

    public void bar() {
        System.out.println(map.get(1));
    }

    public void bar2() {
        System.out.println(nonFinalMap.get(2));
    }
}

我认为这里我们对 bar() 方法有相同的保证 bar2() 不能抛出 NullPointerException 因为 nonVolatileMap assignment 写了更高的 volatile map assignment 但它可以输出 null

---

添加在 Elliott Frisch 评论之后

通过比赛示例发布:

public class Main {
    private static Foo foo;

    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                foo = new Foo();
            }
        }).start();


        new Thread(new Runnable() {
            @Override
            public void run() {
                while (foo == null) ; // empty loop

                foo.bar();
            }
        }).start();

    }
}

请证明或更正我对代码片段的评论。

Answer 1

在当前 Java 内存模型领域，volatile 不等于 final。换句话说，you cannot replace final with volatile ，并认为安全施工保证是一样的。值得注意的是，这在理论上是可以发生的:

public class M {
  volatile int x;
  M(int v) { this.x = v; }
  int x() { return x; }
}

// thread 1
m = new M(42);

// thread 2
M lm;
while ((lm = m) == null); // wait for it
print(lm.x()); // allowed to print "0"

因此，在构造函数中编写 volatile 字段并不安全。

直觉:在上面的示例中，m 上有一场比赛。通过使 field M.x volatile 不会消除该竞争，只会使 m 本身 volatile 会有所帮助。换句话说，该示例中的 volatile 修饰符用在了错误的地方。在安全发布中，您必须具有“写入 -> volatile 写入 -> 观察 volatile 写入 -> 读取的 volatile 读取(现在在 volatile 写入之前观察写入)”，而是具有“ volatile 写入 -> 写入 -> 读取 -> volatile 读(不观察 volatile 写)”。

琐事 1: 这个属性意味着我们可以在构造函数中更积极地优化 volatile-s。这证实了可以放宽未观察到的 volatile 存储(实际上直到具有非转义 this 的构造函数完成后才观察到)的直觉。

知识点 2: 这也意味着您无法安全地初始化 volatile 变量。将上面示例中的 M 替换为 AtomicInteger，您将获得一种奇特的真实行为!在一个线程中调用 new AtomicInteger(42)，不安全地发布实例，然后在另一个线程中执行 get() - 你保证观察到 42?如前所述，JMM 说“不”。 Java 内存模型的较新修订版努力保证所有初始化的安全构造，以捕获这种情况。还有许多重要的非 x86 端口 have already strengthened this为了安全。

知识问答 3: Doug Lea :“这个 final vs volatile 问题导致 java.util.concurrent 中的一些曲折结构允许 0 作为基本/默认值.这条规则很糟糕，应该改变。”

也就是说，这个例子可以做得更巧妙:

public class C {
  int v;
  C(int v) { this.x = v; }
  int x() { return x; }    
}

public class M {
  volatile C c;
  M(int v) { this.c = new C(v); }
  int x() { 
    while (c == null); // wait!
    return c.x();
  }
}

// thread 1
m = new M(42);

// thread 2
M lm;
while ((lm = m) == null); // wait for it
print(lm.x()); // always prints "42"

如果 volatile 字段在 volatile read 观察到构造函数中的 volatile write 写入的值后有传递读取，通常的安全发布规则就会生效。