挥发性出版物的保证深度如何？

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.我列出了class 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转让的书面较高的挥发性映射分配，但它可以输出空

*在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

在当前的Javahtml" target="_blank">html" target="_blank">内存模型领域中，volatile不等于final。换句话说，您不能将替换final为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上面的例子中有一场竞赛。创造 场地 并不能消除种族M.x
volatile，只有制造m自己volatile会有所帮助。换句话说，volatile该示例中的修饰符在 错误的位置
可用。在安全发布中，您必须具有“写入->易失性写入->易失性读取，可观察到易失性写入->读取（现在先观察易失性写入之前的写入）”，而必须具有“易失性写入->写入->读取-

易失性读取（不遵循易失性写入）”。

琐事1：
此属性表示我们可以volatile在构造函数中更加积极地进行优化。这证实了this可以放松未观察到的易失性存储的直觉（实际上，直到具有非转义完成的构造函数才观察到）。

琐事2：
这也意味着您不能安全地初始化volatile变量。在上面的示例中替换M为AtomicInteger，您将具有独特的现实生活行为！调用new AtomicInteger(42)一个线程，不安全地发布该实例，然后get()在另一个线程中执行-
您是否保证遵守42？如前所述，JMM说“不”。Java内存模型的最新修订版努力确保所有初始化的安全构造，以捕获这种情况。许多重要的非x86端口已经加强了它的安全性。

Trivia 3： Doug Lea：“ finalvs
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写入构造函数中写入的值 之后
存在一个传递性直读volatile字段，则通常的安全发布规则开始生效。 __