通过实例程序验证与优化谈谈网上很多对于Java DCL的一些误解以及为何要理解Java内存模型（下）

2. 使用 volatile，这是大家常用以及官方推荐的做法

将 value 设置为 volatile 的，在我的另一系列文章 全网最硬核 Java 新内存模型解析与实验中，我们知道对于 volatile 写入，我们通过在写入之前加入 LoadStore + StoreStore 内存屏障，在写入之后加入 StoreLoad 内存屏障实现的，如果把 value 设置为 volatile 的，那么前面的伪代码就变成了：

我们通过下面的代码测试下：

依旧在 arm 机器上面测试，结果是：

没有看到未初始化值了

3. 对于 Java 9+ 可以使用 Varhandle 的 acquire/release

前面分析，我们其实只需要保证在伪代码第五步之前保证有 StoreStore 内存屏障即可，所以 volatile 其实有点重，我们可以通过使用 Varhandle 的 acquire/release 这一级别的可见性 api 实现，这样伪代码就变成了：

我们的测试代码变成了：

测试结果是：

也是没有看到未初始化值了。这种方式是用内存屏障最少，同时不用限制目标类型里面不必使用 final 字段的方式。

4. 一种有趣但是没啥用的思路 - 如果是静态方法，可以通过类加载器机制实现很简便的写法

如果我们，ValueHolder 里面的方法以及字段可以是 static 的，例如：

将 ValueHolder 作为一个单独的类，或者一个内部类，这样也是能保证 Value 里面字段的可见性的，这是通过类加载器机制实现的，在加载同一个类的时候(类加载的过程中会初始化 static 字段并且运行 static 块代码)，是通过 synchronized 关键字同步块保护的，参考其中类加载器(ClassLoader.java)的源码：

ClassLoader.java

对于 syncrhonized 底层对应的 monitorenter 和 monitorexit，monitorenter 与 volatile 读有一样的内存屏障，即在操作之后加入 LoadLoad 和 LoadStore，monitorexit 与 volatile 写有一样的内存屏障，在操作之前加入 LoadStore + StoreStore 内存屏障，在操作之后加入 StoreLoad 内存屏障。所以，也是能保证可见性的。但是这样虽然写起来貌似很简便，效率上更加低（低了很多，类加载需要更多事情）并且不够灵活，只是作为一种扩展知识知道就好。

总结

1. DCL 是一种常见的编程模式，对于锁保护的字段 value 会有两种字段可见性问题：
2. 如果根据 Java 内存模型的定义，不考虑实际 JVM 的实现，那么 getValue 是有可能返回 null 的。但是这个一般都被现在 JVM 设计避免了，这一点我们在实际编程的时候可以不考虑。
3. 可能读取到没有初始化完成的 Value 的字段值，这个可以通过在构造器完成与赋值给变量之间添加 StoreStore 内存屏障解决。可以通过将 Value 的字段设置为 final 解决，但是不够灵活。
4. 最简单的方式是将 value 字段设置为 volatile 的，这也是 JDK 中使用的方式，官方也推荐这种。
5. 效率最高的方式是使用 VarHandle 的 release 模式，这个模式只会引入 StoreStore 与 LoadStore 内存屏障，相对于 volatile 写的内存屏障要少很多（少了 StoreLoad，对于 x86 相当于没有内存屏障，因为 x86 天然有 LoadLoad，LoadStore，StoreStore，x86 仅仅不能天然保证 StoreLoad）