在新的内存模型中，对双重检查锁定的这个“修复”使 idiom 线程安全。但 是仍然不意味着应当使用这个 idiom！双重检查锁定的要点是，它假定是性能优 化的，设计用于消除公共代码路径的同步，很大程度上因为对于早期的 JDK 来 说，同步是相对昂贵的。不仅非竞争的同步已经便宜 多 了，而且对 volatile 语义的新改变也使它在某些平台上比旧的语义昂贵得多。（实际上，对 volatile 字段的每一次读或者写都像是“半个”同步——对 volatile 的读有 与监视器所获得的同样的内存语义，对 volatile 的写有与监视器所释放的同样 的语义。）所以如果双重检查锁定的目标是提供比更直观的同步方式更好的性能 ，那么这个“修复的”版本也没有多大帮助。

不使用双重检查锁定，而使用 Initialize-on-demand Holder Class idiom ，它提供了迟缓初始化，是线程安全的，而且比双重检查锁定更快且没那么混乱 ：

清单 2. Initialize-On-Demand Holder Class idiom

private static class LazySomethingHolder { 　 public static Something something = new Something(); } ... public static Something getInstance() { 　 return LazySomethingHolder.something; }

这个 idiom 由属于类初始化的操作（如静态初始化器）保证对使用这个类的 所有线程都是可见的这一事实衍生其线程安全性，内部类直到有线程引用其字段 或者方法时才装载这一事实衍生出迟缓初始化。

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

初始化安全性

新的 JMM 还寻求提供一种新的 初始化安全性 保证——只要对象是正确构造 的（意即不会在构造函数完成之前发布对这个对象的引用），然后所有线程都会 看到在构造函数中设置的 final 字段的值，不管是否使用同步在线程之间传递 这个引用。而且，所有可以通过正确构造的对象的 final 字段可及的变量，如 用一个 final 字段引用的对象的 final 字段，也保证对其他线程是可见的。这 意味着如果 final 字段包含，比如说对一个 LinkedList 的引用，除了引用的 正确的值对于其他线程是可见的外，这个 LinkedList 在构造时的内容在不同步 的情况下，对于其他线程也是可见的。结果是显著增强了 final 的意义——可 以不用同步安全地访问这个 final 字段，编译器可以假定 final 字段将不会改 变，因而可以优化多次提取。

Final 意味着最终

在 第 1 部分描述了在旧的内存模型中，final 字段的值似乎可以改变的一 种机制——在不使用同步时,另一个线程会首先看到 final 字段的默认值，然后 看到正确的值。

在新的内存模型中，在构造函数的 final 字段的写与在另一个线程中对这个 对象的共享引用的初次装载之间有一个类似于 happens-before 的关系。当构造 函数完成任务时，对 final 字段的所有写（以及通过这些 final 字段间接可及 的变量）变为“冻结”，所有在冻结之后获得对这个对象的引用的线程都会保证 看到所有冻结字段的冻结值。初始化 final 字段的写将不会与构造函数关联的 冻结后面的操作一起重新排序。

结束语

JSR 133 显著增强了 volatile 的语义，这样就可以可靠地使用 volatile 标志表明程序状态被另一个线程改变了。作为使 volatile 更“重量级”的结果 ，使用 volatile 的性能成本更接近于某些情况下同步的性能成本，但是在大多 数平台上性能成本仍然相当低。JSR 133 还显著地增强了 final 的语义。如果 一个对象的引用在构造阶段不允许逸出（escape），那么

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