个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~本文基于 OpenJDK 11 以上的版本
最近爆肝了这系列文章 全网最硬核 Java 新内存模型解析与实验，从底层硬件，往上全面解析了 Java 内存模型设计，并给每个结论都配有了相关的参考的论文以及验证程序，我发现多年来对于 Java 内存模型有很多误解，并且我发现很多很多人都存在这样的误解，所以这次通过不断优化一个经典的 DCL （Double Check Locking）程序实例来帮助大家消除这个误解。
首先有这样一个程序, 我们想实现一个单例值，只有第一次调用的时候初始化，并且有多线程会访问这个单例值，那么我们会有：
getValue 的实现就是经典的 DCL 写法。
在 Java 内存模型的限制下，这个 ValueHolder 有两个潜在的问题：
- 如果根据 Java 内存模型的定义，不考虑实际 JVM 的实现，那么 getValue 是有可能返回 null 的。
- 可能读取到没有初始化完成的 Value 的字段值。
下面我们就这两个问题进行进一步分析并优化。
根据 Java 内存模型的定义，不考虑实际 JVM 的实现，getValue 有可能返回 null 的原因
在 全网最硬核 Java 新内存模型解析与实验 文章的7.1. Coherence（相干性，连贯性）与 Opaque中我们提到过：假设某个对象字段 int x 初始为 0，一个线程执行：
另一个线程执行(r1, r2 为本地变量)：
那么这个实际上是两次对于字段的读取（对应字节码 getfield），在 Java 内存模型下，可能的结果是包括：
r1 = 1, r2 = 1r1 = 0, r2 = 1r1 = 1, r2 = 0r1 = 0, r2 = 0
其中第三个结果很有意思，从程序上理解即我们先看到了 x = 1，之后又看到了 x 变成了 0.实际上这是因为编译器乱序。如果我们不想看到这个第三种结果，我们所需要的特性即 coherence。这里由于private Value value是普通的字段，所以根据 Java 内存模型来看并不保证 coherence。
回到我们的程序，我们有三次对字段读取（对应字节码 getfield），分别位于:
由于 1，2 之间有明显的分支关系（2 根据 1 的结果而执行或者不执行），所以无论在什么编译器看来，都要先执行 1 然后执行 2。但是对于 1 和 3，他们之间并没有这种依赖关系，在一些简单的编译器看来，他们是可以乱序执行的。在 Java 内存模型下，也没有限制 1 与 3 之间是否必须不能乱序。所以，可能你的程序先执行 3 的读取，然后执行 1 的读取以及其他逻辑，最后方法返回 3 读取的结果。
但是，在 OpenJDK Hotspot 的相关编译器环境下，这个是被避免了的。OpenJDK Hotspot 编译器是比较严谨的编译器，它产生的 1 和 3 的两次读取（针对同一个字段的两次读取）也是两次互相依赖的读取，在编译器维度是不会有乱序的（注意这里说的是编译器维度哈，不是说这里会有内存屏障连可能的 CPU 乱序也避免了，不过这里针对同一个字段读取，前面已经说了仅和编译器乱序有关，和 CPU 乱序无关）
不过，这个仅仅是针对一般程序的写法，我们可以通过一些奇怪的写法骗过编译器，让他任务两次读取没有关系，例如在全网最硬核 Java 新内存模型解析与实验 文章的7.1. Coherence（相干性，连贯性）与 Opaque中的实验环节，OpenJDK Hotspot 对于下面的程序是没有编译器乱序的：
但是如果你换成下面这种写法，就骗过了编译器：
我们不用太深究其原理，直接看其中一个结果：
对于 DCL 这种写法，我们也是可以骗过编译器的，但是一般我们不会这么写，这里就不赘述了。
可能读取到没有初始化完成的 Value 的字段值
这个就不只是编译器乱序了，还涉及了 CPU 指令乱序以及 CPU 缓存乱序，需要内存屏障解决可见性问题。
我们从 Value 类的构造器入手：
对于 value = new Value(10); 这一步，将代码分解为更详细易于理解的伪代码则是：
这中间没有任何内存屏障，根据语义分析，1 与 5 之间有依赖关系，因为 5 依赖于 1 的结果，必须先执行 1 再执行 5。 2 与 3 之间也是有依赖关系的，因为 3 依赖 2 的结果。但是，2和3，与 4，以及 5 这三个之间没有依赖关系，是可以乱序的。我们使用使用代码测试下这个乱序：
虽然在注释中写出了这么编写代码的原因，但是这里还是想强调下这么写的原因：
- jcstress 的 @Actor 是使用一个线程执行这个方法中的代码，在测试中，每次会用不同的 JVM 启动参数让这段代码解释执行，C1编译执行，C2编译执行，同时对于 JIT 编译还会修改编译参数让它的编译代码效果不一样。这样我们就可以看到在不同的执行方式下是否会有不同的编译器乱序效果。
- jcstress 的 @Actor 是使用一个线程执行这个方法中的代码，在每次使用不同的 JVM 测试启动时，会将这个 @Actor 绑定到一个 CPU 执行，这样保证在测试的过程中，这个方法只会在这个 CPU 上执行， CPU 缓存由这个方法的代码独占，这样才能更容易的测试出 CPU 缓存不一致导致的乱序。所以，我们的 @Actor 注解方法的数量需要小于 CPU 个数。
- 我们测试机这里只有两个 CPU，那么只能有两个线程，如果都执行原始代码的话，那么很可能都执行到 synchronized 同步块等待，synchronized 本身有内存屏障的作用（后面会提到）。为了更容易测试出没有走 synchronized 同步块的情况，我们第二个 @Actor 注解的方法直接去掉同步块逻辑，并且如果 value 为 null，我们就设置结果都是 -1 用来区分
