Java内存模型-工作内存、主内存、原子性、有序性、可见性、volatile、synchronized
文章目录
- 一、概念
- 二、背景
- 2.1 高速缓存
- 2.1 缓存一致性
- 2.3 乱序执行
- 2.4 引入Java内存模型
- 三、Java内存模型
- 3.1 主内存与工作内存
- 3.2 内存间交互操作
- 3.2.1 8种操作
- 3.2.2 执行规则
- 四、多线程三大特征
- 4.1 原子性（Atomicity）
- 4.2 可见性（Visibility）
- 4.3 有序性（Ordering）
- 五、先行发生原则（happens-before）
- 六、内存屏障
- 6.1 CPU内存屏障
- 6.2 JMM内存屏障
- 6.3 volatile内存屏障
- 6.4 volatile 性能
- 七、volatile关键字
- 7.1 volatile不保证原子性
- 7.2 volatile可见性
- 7.3 volatile有序性
- 7.4 何时使用
- 八、单例模式——双重检测
- 8.1 错误分析
- 8.2 从内存屏障的角度分析
- 8.3 从先行发生原则的角度分析
一、概念
- Java内存模型：Java Memory Model，简称 JMM
- Java内存模型是Java虚拟机规范的一部分
- Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
- Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的。
- Java虚拟机规范中试图定义一种Java内存模型，来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。
一句话，Java内存模型是为了解决多线程安全问题的一种Java虚拟机实现的规范。
二、背景
程序，就是指令与数据的集合，指令由处理器执行，指令对象为内存中的数据
数据在处理器和内存之间的交互图
2.1 高速缓存
处理器的运算速度比主内存的读写速度要快得多（几个数量级），如果处理器直接与主内存交互，那处理器在访问内存时就要花很长时间来等待内存的操作，所以在处理器与主内存之间加上高速缓存作为缓冲，减少处理器的等待时间。
将运算需要用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回主内存中，这样处理器就无需等待缓慢的内存读写了。
2.1 缓存一致性
基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（Cache Coherence）。
当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？
所以，高速缓存与主内存之间的交互，需要遵循一些协议，这些协议就是为了解决缓存一致性而存在的
多线程安全问题
2.3 乱序执行
为了使得处理器内部的运算单元尽量被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致。
Java虚拟机的即时编译器中也有类似的指令重排序优化
2.4 引入Java内存模型
Java虚拟机规范中试图定义一种Java内存模型，来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。
平台开关性，同一套代码不能在一个平台上线程安全，在另一个平台上就出问题
三、Java内存模型
Java内存模型的主要目标是定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。
此处的变量（Variables）与Java编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但不包括局部变量与方法参数（如果局部变量是一个reference类型，它引用的对象在Java堆中可被各个线程共享，但是reference本身在Java栈的局部变量表中，它是线程私有的）
主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节
3.1 主内存与工作内存
Java内存模型还定义了主内存、工作内存，线程间变量值的传递均需要通过主内存来完成
- 主内存类比物理机的主内存，是虚拟机内存中存储共享变量的区域
- 工作内存类比物理机的高速缓存，保存了被该线程使用到的变量的主内存的副本拷贝
- JMM比物理机的缓存一致性
注意：
- 主内存与工作内存，是一个抽象的概念，并不真实存在
- 这里所讲的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分
- 勉强对应的话
- 主内存主要对应于Java堆中的对象实例数据部分
- 工作内存则对应于虚拟机栈中的部分区域
- 从更低层次上说
- 主内存直接对应于物理硬件的内存
- 为了获取更好的运行速度，虚拟机（甚至是硬件系统本身的优化措施）可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时访问读写的是工作内存
为了获得较好的执行效能，Java内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施
总的来说，虚拟机把运行内存、物理内存（文件）、堆、方法区等存储共享数据的地方，抽象成主内存；把寄存器、高速缓存、栈等存储私有数据的地方，抽象成工作内存。
3.2 内存间交互操作
Java内存模型定义了8种操作，来实现主内存和工作内存之间的交互，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节。
这8种操作，虚拟机实现时，必须保证都是原子的，不可再分的。
double、long类型在某些平台上允许有例外
3.2.1 8种操作
- lock（锁定）：作用于主内存的变量，它把一个变量标识为一个线程独占的状态。只有遇到特定指令时，才会对变量进行lock操作
字节码指令为monitorenter，对应的Java关键字为synchronized
- unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
- read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。
- load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
- use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。
- assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
- store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
- write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。
3.2.2 执行规则
- 不允许read和load、store和write操作之一单独出现，即允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现。
- 不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
- 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
- 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说，就是对一个变量实施use、store操作之前，必须先执行过了assign和load操作。
- 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
- 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
- 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，好不允许unlock一个被其他线程锁定住的变量。
- 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。
四、多线程三大特征
多线程安全问题产生的根本原因？
下面三个特征，有一个不符合，就有可能出现多线程安全问题
- 原子性
- 可见性
- 有序性
Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的。
只要代码保证了这三个特征，就是线程安全的
4.1 原子性（Atomicity）
原子性的一般定义为：一个或多个操作，要么都执行成功，要么都不执行。
在多线程中，原子性，就是代码在被一个线程在执行时，排斥其它线程。
由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store、和write，我们大致可以认为基本数据类型的访问读写是具备原子性的（long和double有非原子性协定，但无须太过在意这些几乎不会发生的例外情况）。
如果应用场景需要一个更大范围的原子性保证，Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。
Java语言提供synchronized保证原子性
4.2 可见性（Visibility）
可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。
Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。
Java语言提供volatile、synchronized保证可见性
synchronized怎么保证可见性？
public class VolatileTest2 {
private static int number = 0;
private static class ReaderThread extends Thread {
@Override
public void run() {
if (number == 0) {
System.out.println("synchronized外，线程" + Thread.currentThread().getName() + "，number = " + number);
Thread.yield();
synchronized (VolatileTest2.class) {
System.out.println("synchronized内，线程" + Thread.currentThread().getName() + "，number = " + number);
if (number == 0) {
number = 1;
System.out.println("synchronized内，线程" + Thread.currentThread().getName() + "，修改number，number = " + number);
Thread.yield();
}
}
}
}
}
public static void main(String[] args) {
new ReaderThread().start();
new ReaderThread().start();
}
}
输出
synchronized外，线程Thread-0，number = 0
synchronized内，线程Thread-0，number = 0
synchronized内，线程Thread-0，修改number，number = 1
synchronized外，线程Thread-1，number = 0
synchronized内，线程Thread-1，number = 1
synchronized怎么保证可见性？
- 线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新获取最新的值
- 线程解锁前，必须把共享变量的最新值刷新到主内存中
注意：这里清空的工作内存，是本线程的工作内存，其它线程的工作内存不会被清空
结论：synchronized保证的是同一个块内的共享变量的可见性，其在块外的可见性不会被保证
4.3 有序性（Ordering）
有序性分时间有序性和语义有序性，JVM保证单线程下指令执行的语义有序性，CPU保证自身指令执行的语义有序性。
JVM和CUP都存在指令重排序的情况，都是为了提高并行度、提高程序运行效率。
- 时间有序性：就是按代码先后顺序执行。
- 语义有序性
- JVM语义有序性：在单线程中，乱序执行结果与顺序执行结果一致。
- CPU语义有序性：在单核中，乱序执行结果与顺序执行结果一致。
就是对没有依赖关系的指令，可以进行乱序执行。
如
int a = 1; // 1
int b = a + 1; // 2
int c = 2; // 3
在这个例子中，3与1，3与2都没有依赖关系，所以3可以先执行，也可以在中间执行，还可以在最后执行；而1与2有依赖关系，2只能在1执行后再执行
volatile保证时间有序性，是指所修饰变量前后的代码不能重排序，但是前和后的代码可以分别重排序。
Java语言提供volatile、synchronized保证有序性
final变量也可以保证有序性
synchronized怎么保证有序性的？
synchronized是通过排斥其它线程，实现的排队执行synchronized代码块的有序性，但是，它并不能保证块内代码执行的有序性。换句话说，synchronized保证的是整体的有序性，不保证内部的有序性。
五、先行发生原则（happens-before）
注意：代码先不一定就先行发生
先行发生原则是判断数据是否存在竞争、线程是否安全的主要依据。
先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，其它就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。
注意：
- 先行发生不等于代码书写在前，代码书写在前不等于先行发生。
- happens-before规则不是描述实际操作的先后顺序，它是用来描述可见性的一种规则
如果代码符合以下规则之一，就是天然的先行发生，就是线程安全的（在保证原子性的前提下）。
-
程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
-
管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，面“后面”是指时间上的先后顺序。
如果线程1解锁了monitor a，接着线程2锁定了a，那么，线程1解锁a之前的写操作都对线程2可见（线程1和线程2可以是同一个线程）。这里强调的是同一个锁！
- 对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。
如果线程1写入了volatile变量v（这里和后续的“变量”都指的是对象的字段、类字段和数组元素），接着线程2读取了v，那么，线程1写入v及之前的写操作都对线程2可见（线程1和线程2可以是同一个线程）。
-
线程启动规则（Thrad Start Rule）：Thread对象的start()方法先行发生于此线程的每一个动作。
-
线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
-
线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测到是否有中断发生。
-
对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。
-
传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。
六、内存屏障
6.1 CPU内存屏障
语言的尽头都是机器指令，CPU指令集也针对乱序执行也有相关指令，这里我们以x86为例
- sfence: 内存写屏障，保证这条指令前的所有的存储指令必须在这条指令之前执行，并且在执行此条指令时把写入到CPU的私有缓存的数据刷到公有内存
- lfence: 内存读屏障，保证这条指令后的所有读取指令在这条指令后执行，并且执行此条指令时，清空CPU的读取缓存，也就是说强制接下来的load从主存中取数据
- mfence: full barrier，代价最大的barrier，有上述两种barrier的效果，当然也是最稳健的的barrier
- lock: 这个是一种同步指令，也可以禁止lock前的指令和之后的指令重排序(这个指令还可以实现很多功能)，lock也许是很多JVM底层使用的指令
上述只是x86指令集下的相关指令，不同的指令集可能barrier的效果并不一样，fence和lock是两种实现内存屏障的方式(毕竟一个指令集很庞大)
6.2 JMM内存屏障
JMM也定义了4种内存屏障（JVM再使用CPU指令去实现这些语义）
- LoadLoad：
Load1;LoadLoad;Load2，确保 Load1 数据的装载，之前于 Load2 及所有后续装载指令的装载。保证Load1要读取的数据被读取完毕 - StoreStore：
Store1;StoreStore;Store2，确保 Store1 数据对其他处理器可见(刷新到内存)，之前于Store2 及所有后续存储指令的存储。保证Store1的写入操作对其它处理器可见 - LoadStore：
Load1;LoadStore;Store2，Load1 数据装载，之前于Store2 及所有后续的存储指令刷新到内存。保证Load1要读取的数据被读取完毕 - StoreLoad：
Store1;StoreLoad;Load2，确保 Store1 数据对其他处理器变得可见(指刷新到内存)，之前于Load2 及所有后续装载指令的装载。StoreLoad Barriers 会使该屏障之前的所有内存访问指令(存储和装载指令)完成之后，才执行该屏障之后的内存访问指令。这个屏障是个万能屏障，兼具其它三种内存屏障的功能
注意
- 对于不同的处理器/指令集（平台），JVM有不同的实现方式，比如有可能在x86上一个StoreLoad会使用mfence去实现(猜测)
- 这四个barrier是JVM内存模型的规范，而不是具体的字节码指令，volatile变量在字节码中只是一个标志位，javap反编译是没有barriers的，只是说JVM执行引擎会在执行时会插一个对应的屏障，或者说在JIT/AOT生成机器指令的时候插一条对应逻辑的barriers，说句人话，这个barrier不是javac插的！
总结
到这里我们可以看到，其实不存在任何一种指令能够禁止乱序执行，我们能做到的只是把这一堆指令根据“分段”，比如在指令中插入一条full barrier指令，然后所有指令被分成了两段，barrier前面的我们称之为程序段A，后面的称之为程序段B，通过barrier我们能够保证A所有指令的执行都在B之前，也就是说，程序段A和B分别都是乱序执行的。
总结下来，内存屏障有三个作用：
- 阻止屏障两侧的指令重排序
- 强制把写缓冲区/高速缓存中的脏数据等写回主内存
- 让其它CPU/内核的缓存中相应的数据失效
6.3 volatile内存屏障
volatile的内存屏障策略非常严格保守，非常悲观且毫无安全感的心态：
- 在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；
- 在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；
由于内存屏障的作用，避免了volatile变量和其它指令重排序、实现了线程之间的通信，使得volatile表现出了锁的特性。
6.4 volatile 性能
volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。
七、volatile关键字
volatile可以保证可见性、有序性（禁止指令重排）
它是Java虚拟机提供的最轻量级的同步机制
-
volatile怎么保证可见性？
- 线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新获取最新的值
- 线程解锁前，必须把共享变量的最新值刷新到主内存中
-
volatile怎么保证有序性？
- 操作volatile变量时，不管读操作还是写操作，都不允许它前后的代码进行重排序
- 这里是指以它为分割线切开，分成几个部分，各个小部分内部还是可以重排序的
注意：volatile关键字在jdk1.5后才被完全修复，在1.4及之前的版本，volatile变量前后的代码仍然存在重排序的问题。
7.1 volatile不保证原子性
基于volatile变量的运算在并发下是安全的，这是错误的（它不保证原子性）
示例代码
public class VolatileTest {
private static volatile int race = 0;
private static void increase() {
race++;
}
public static void main(String[] args) throws Exception {
Thread[] threads = new Thread[20];
for (int i = 0; i < 20; i++) {
threads[i] = new Thread(() -> {
for (int j = 0; j < 10000; j++) {
increase();
}
});
threads[i].start();
}
for (Thread t : threads) {
while (t.isAlive()) {
Thread.sleep(100);
}
}
System.out.println(race);
}
}
输出
125637
原因？
race++;这句代码，编译成Class文件时，由4个字节码指令构成，分别是getstatic、iconst_1、iadd、putstatic，
- getstatic：获取类的静态字段值
- iconst_1：将int类型常量值1入栈到操作数栈中（每次+1）
- iadd：int类型数据相加
- putstatic：设置类的静态字段值
一条字节码指令，并不一定就是一个原子操作，如这里，这4个字节码，需要read、load、use、assign、stroe、write6个Java内存模型定义的原子操作来完成，当然，如果
race++;被synchronized修饰，那这4个字节码就是原子操作的一部分了。
从字节码上分析原因：当getstatic指令把race的值取到操作栈顶时，volatile关键字保证了race的值在些时是正确的，但是在执行iconst_1、iadd这些指令的时候，其他线程可能已经把race的值加大了，而在操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步回主内存之中。
根本原因：变量的操作不是原子操作
解决办法很多，如使用synchronized或java.util.concurrent中的原子类
7.2 volatile可见性
private static volatile SingleInstance instance;
instance = new SingleInstance(); // 1
语句1转换成汇编代码，在赋值给instance后，会多一个指令，lock addl $0x0,(%esp)，addl $0x0,(%esp)（把ESP寄存器的值加0）是一个空操作，目的是使用lock指令，原因是lock不能搭配空操作指令nop使用。lock的作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化（Invalidate）其Cache，这种操作相当于对Cache中的变量做了一次前面介绍Java内存模型中所说的“store”和“write”操作。所以通过这样一个操作，可让前面volatile变量的修改对其它CPU立即可见。
通俗地说，对volatile变量的修改，会立即同步回主内存，并且会无效化其它线程中的缓存
lock addl $0x0,(%esp)这个指令就是传说中的“内存屏障”
7.3 volatile有序性
由于lock指令可以禁止其前后代码的重排序，自其前的代码肯定先执行于其后的代码
7.4 何时使用
当代码符合以下两条规则时，可使用volatile保证线程安全
- 运算结果并不依赖变量的当前值，或者能够保证只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
第一条很好理解，就是上面的代码例子。第二条是什么意思呢？可以看看下面这个场景：
volatile static int start = 3;
volatile static int end = 6;
线程A执行如下代码：
while (start < end){
//do something
}
线程B执行如下代码：
start+=3;
end+=3;
这种情况下，一旦在线程A的循环中执行了线程B，start有可能先更新成6，造成了一瞬间 start == end，从而跳出while循环的可能性。
下面这种情况，适合使用volatile
volatile boolean shutdownRequested;
public void shutdown() {
shutdownRequested = true;
}
public void doWord() {
while(!shutdownRequested) {
// do stuff
}
}
shutdownRequested的赋值不依赖原值，也与其它变量无关
八、单例模式——双重检测
DCL(double-checked locking)
是不是使用synchronized，线程就一定安全？
public class SingletonClass4 {
private static SingletonClass4 instance;
private int someField;
private SingletonClass4() {
this.someField = 1;
}
public static SingletonClass4 getInstance() {
if (instance == null) {
synchronized (SingletonClass4.class) {
if (instance == null) {
instance = new SingletonClass4();
}
}
}
return instance;
}
public int getSomeField() {
return this.someField;
}
}
8.1 错误分析
网络上普遍存在的说法
1. 什么原因
instance = new SingletonClass4();这段代码会被转换成多个指令，简化成三个步骤
(1) memory=allocate(); // 分配DCL类实例需要的内存空间
(2) ctorInstance(memory); // 通过构造函数对内存空间进行初始化
(3) instance=memory; // 将内存空间地址赋值给instance对象引用
由于JVM和CPU都存在乱序执行的情况，当执行顺序为（3）->（2）时，就可能造成其它线程使用了没初始化完成的对象，从而出现问题。
(1) memory=allocate(); // 分配DCL类实例需要的内存空间
(3) instance=memory; // 将内存空间地址赋值给instance对象引用
(4) instance.getSomeField(); // 这里，可能就得到someField的初始值0
(2) ctorInstance(memory); // 通过构造函数对内存空间进行初始化
这就是传说中的对象逸出
- 对象发布（Publish）：提供一个对象的引用给作用域之外的代码使用
- 对象逸出（Escape）：发布一个尚未初始化完成的对象
2. 怎么解决
使用volatile修饰instance变量
3. 为什么
volatile可以禁止JVM和CPU重排序，也就是说（3）不会先于（2）执行，也就不存在对象逸出问题了。
8.2 从内存屏障的角度分析
当instance被volatile修饰，翻译成汇编代码后，会在变量赋值后，加上一个内存屏障
instance = new SingleInstance();
(1) memory=allocate(); // 分配DCL类实例需要的内存空间
(2) ctorInstance(memory); // 通过构造函数对内存空间进行初始化
(3) instance=memory; // 将内存空间地址赋值给instance对象引用
StoreLoad -> lock
(4) instance.getSomeField(); // 不管(2)(3)以什么顺序执行，这里都是返回赋值后的1
回顾一下StoreLoad的作用：在指令前执行的写操作完成后，才可以执行之后的读操作
这样，lock后的操作不会重排序到lock前执行，lock前的操作不会重排序到lock后执行，这就是volatile变量保证时间有序性的体现。
而且，lock指令，还会保证它前面的操作都已经执行完毕，才会执行lock后面的操作，也就不存在对象逸出问题了。
结论：加上volatile修饰instance后，并不会禁止(1)(2)(3)重排序！
但是，这样只能说明了在同一个线程内是安全的，而DCL是另外的线程去读这个instance变量。内存屏障怎么保证该变量修改后，在其它线程使用也是安全的呢？
这是因为，lock还有一个作用是使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU或者别的内核无效化（Invalidate）其Cache，这种操作相当于对Cache中的变量做了一次前面介绍Java内存模型中所说的“store”和“write”操作。所以通过这样一个操作，可让前面volatile变量的修改对其它CPU立即可见。
8.3 从先行发生原则的角度分析
先行发生是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，其它就是说在发生操作B之前，操作A产生的影响能被操作B观察到，“影响”包括修改了内存中共享变量的值、发送了消息、调用了方法等。
8条规则在上面
public class SingletonClass4 {
private static SingletonClass4 instance;
private int someField;
private SingletonClass4() {
this.someField = 1; // (1)
}
public static SingletonClass4 getInstance() {
if (instance == null) { // (2)
synchronized (SingletonClass4.class) { // (3)
if (instance == null) { // (4)
instance = new SingletonClass4(); // (5)
}
}
}
return instance; // (6)
}
public int getSomeField() {
return this.someField; // (7)
}
}
场景：线程1执行getInstance()到(5)时，线程挂起，紧接着线程2执行int someField = getInstance().getSomeField()到(2)，这里分两种情况
- instance == null
- instance != null
当语句A happens-before B时，用hb(A, B)表示
目的：只要说明hb(1, 7)不成立，那4可能返回0，也可能返回1。
先分析第1种情况：instance == null
- 当线程1退出同步块后，线程2进入同步块，执行(4)，这时instance还为null吗？
- 线程1的unlock，时间上先于线程2的lock，由管程锁定规则可知，hb(unlock, lock)，由程序次序规则可得hb(5, unlock)、hb(lock, 4)，由传递性可得hb(5, 4)，也就是(5)的操作结果对(4)可见，所以线程2在(4)处的结果必不为null
- 对于线程2，执行顺序为(4)(6)(7)，同一线程内，所以hb(4, 6)、hb(6, 7)
- 同一线程内，由(1)在unlock之前，即hb(1, unlock)，结合hb(unlock, lock)、hb(lock, 4)，可得hb(1, 4)，再结合hb(4, 6)、hb(6, 7)，可得hb(1, 7)，也就是(1)的结果对(7)可见，所以(7)处返回的结果必为1
结论：第1种情况的结果是正确的
再分析第2种情况：instance != null
- instance != null，也就是线程2观察到了线程1对instance的写入，这时线程2就会执行语句(6)直接返回这个instance的值，然后对这个instance调用getSomeField()方法
- 线程2从开始到结束，整个过程没有经过任何同步器，那就没办法使用8条先行发生原则去判断(1)与(7)的先行发生关系了
- 线程2执行语句(7)完全有可能观测不到线程2在语句(1)处对someFiled写入的值，这就是DCL的问题所在
结论：第种情况，线程2得到的结果可能是0，也可能是1
怎么解决呢？
办法很多，这里用volatile修饰instance变量private static volatile SingletonClass4 instance;
再用先行发生原则分析一下：
既然问题出在instance != null，那就直接对这种情况进行分析
- 虽然线程2从开始到结束，整个过程没有经过任何同步器，但是加了volatile后，我们就可以使用第3条规则（volatile变量规则）了
- 由于线程2在(2)处得到instance != null，所以线程1必定已经执行了(5)，也就是(5)已经发生了，可得hb(5, 2)
- 由程序次序规则对于线程1，可得hb(1, 5)，对于线程2，可得hb(2, 7)
- 结合hb(1, 5)、hb(5, 2)、hb(2, 7)，可得hb(1, 7)，也就是(1)对(7)可见
结论：用volatile修饰instance变量，可解决DCL问题