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)的源码：
对于 syncrhonized 底层对应的 monitorenter 和 monitorexit，monitorenter 与 volatile 读有一样的内存屏障，即在操作之后加入 LoadLoad 和 LoadStore，monitorexit 与 volatile 写有一样的内存屏障，在操作之前加入 LoadStore + StoreStore 内存屏障，在操作之后加入 StoreLoad 内存屏障。所以，也是能保证可见性的。但是这样虽然写起来貌似很简便，效率上更加低（低了很多，类加载需要更多事情）并且不够灵活，只是作为一种扩展知识知道就好。
总结
- DCL 是一种常见的编程模式，对于锁保护的字段 value 会有两种字段可见性问题：
- 如果根据 Java 内存模型的定义，不考虑实际 JVM 的实现，那么 getValue 是有可能返回 null 的。但是这个一般都被现在 JVM 设计避免了，这一点我们在实际编程的时候可以不考虑。
- 可能读取到没有初始化完成的 Value 的字段值，这个可以通过在构造器完成与赋值给变量之间添加 StoreStore 内存屏障解决。可以通过将 Value 的字段设置为 final 解决，但是不够灵活。
- 最简单的方式是将 value 字段设置为 volatile 的，这也是 JDK 中使用的方式，官方也推荐这种。
- 效率最高的方式是使用 VarHandle 的 release 模式，这个模式只会引入 StoreStore 与 LoadStore 内存屏障，相对于 volatile 写的内存屏障要少很多（少了 StoreLoad，对于 x86 相当于没有内存屏障，因为 x86 天然有 LoadLoad，LoadStore，StoreStore，x86 仅仅不能天然保证 StoreLoad）
