不幸地，这是 volatile 常见用例——用一个 volatile 字段作为“守护” 表明已经初始化了一组共享变量。JSR 133 Expert Group 决定让 volatile 读 写不能与其他内存操作一起重新排序是有意义的——可以准确地支持这种和其他 类似的用例。在新的内存模型下，如果当线程 A 写入 volatile 变量 V 而线程 B 读取 V 时，那么在写入 V 时，A 可见的所有变量值现在都可以保证对 B 是 可见的。结果就是作用更大的 volatile 语义，代价是访问 volatile 字段时会 对性能产生更大的影响。

Java理论与实践: 修复Java内存模型，第2部分(2)

在这之前发生了什么？

像对变量的读写这样的操作，在线程中是根据所谓的“程序顺序”——程序 的语义声明它们应当发生的顺序——排序的。（编译器实际上对在线程中使用程 序顺序是可以有一些自由的——只要保留了 as-if-serial 语义。）在不同线程 中的操作完全不一定要彼此排序——如果启动两个线程并且它们对任何公共监视 器都不用同步执行、或者涉及任何公共 volatile 变量，则完全 无法准确地预 言一个线程中的操作（或者对第三个线程可见）相对于另一个线程中操作的顺序 。

此外，排序保证是在线程启动、一个线程参与另一个线程、一个线程获得或 者释放一个监视器（进入或者退出一个同步块）、或者一个线程访问一个 volatile 变量时创建的。JMM 描述了程序使用同步或者 volatile 变量以协调 多个线程中的活动时所进行的的顺序保证。新的 JMM 非正式地定义了一个名为 happens-before 的排序，它是程序中所有操作的部分顺序，如下所示：

线程中的每一个操作 happens-before这个线程中在程序顺序中后面出现的每 一个操作

对监视器的解锁 happens-before同一监视器上的所有后续锁定

对 volatile 字段的写 happens-before同一 volatile 的每一个后续读

对一个线程的 Thread.start() 调用 happens-before在启动的线程中的所有 操作

线程中的所有操作 happens-before 从这个线程的 Thread.join() 成功返回 的所有其他线程

这些规则中的第三个——控制对 volatile 变量的读写，是新的并且修正了 清单 1 中的例子的问题。因为对 volatile 变量 initialized 的写是在初始化 configOptions 之后发生的， configOptions 的使用是在 initialized 的读后 发生的，而对 initialized 的读是在对 initialized 的写后发生的，因此可以 得出结论，线程 A 对 configOptions 的初始化是在线程 B 使用 configOptions 之前发生的。因而 configOptions 和通过它可及的变量对于线 程 B 是可见的。

图 1. 用同步保证跨线程的内存写的可见性

数据争用

当有一个变量被多个线程读、被至少一个线程写、并且读和写不是按 hanppens-before 关系排序的时，程序就称为有 数据争取（data race），因而 不是一个“正确同步”的程序。

这是否修改了双重检查锁定的问题？

对双重检查锁定问题提出的一种修复是使包含迟缓初始化的实例的字段为一 个 volatile 字段。（有关双重检查锁定的问题和对为什么所建议的算法修复不 能解决问题的说明请参阅 参考资料。）在旧的内存模型中，这不能使双重检查 锁定成为线程安全的，因为对 volatile 字段的写仍然会与对其他 nonvolatile 字

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!