Java并发编程——共享模型之内存（ JMM、-原子性、可见性、有序性、volatile原理）
之前讲的synchronized底层Monitor主要关注的是访问共享变量时，保证临界区代码的原子性 。
下面进一步深入学习共享变量在多线程间的【可见性】问题与多条指令执行时的【有序性】问题。
一、 Java 内存模型
JMM 即 Java Memory Model ，它从Java层面定义了 主存、工作内存 抽象概念，底层对应着CPU 寄存器、缓存、硬件内存、CPU 指令优化等。JMM 体现在以下几个方面
- 原子性 - 保证指令不会受 线程上下文切换的影响
- 可见性 - 保证指令不会受 cpu 缓存的影响 (JIT对热点代码的缓存优化)
- 有序性 - 保证指令不会受 cpu 指令并行优化的影响
1.1 概念
JMM是一个抽象的概念，并不是物理上的内存划分。
Java内存模型（JMM）定义了Java虚拟机（JVM）在计算机内存（RAM）中的工作规范。在硬件内存模型中，各种CPU架构的实现是不尽相同的，Java作为跨平台的语言，为了屏蔽底层硬件差异，定义了Java内存模型（JMM）。JMM作用于JVM和底层硬件之间，屏蔽了下游不同硬件模型带来的差异，为上游开发者提供了统一的使用接口。说了这么多其实就是想说明白JMM——JVM——硬件的关系。总之一句话，JMM是JVM的内存使用规范，是一个抽象的概念。
所有的变量都存储在主内存中每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存该变量的一份拷贝）。
操作内存的两条规定：
- 线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主内存中读写。
- 不同线程之间
无法直接访问其他线程工作内存中的变量，线程间值的传递需要通过主内存来完成。
JMM关于synchronized的两条规定：
- 线程解锁前，必须把
共享变量的最新值刷新到主内存中 - 线程加锁时，将
清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值。（加锁和解锁需要是同一把锁） - 线程解锁前对共享变量的修改在下次加锁前对其他线程可见。
1.2 内存结构
JVM将内存为主内存和工作内存两个部分。
主内存: 主要包括本地方法区和 堆
- Java 内存模型规定了
所有变量都存储在主内存(Main Memory)中（此处的主内存与介绍物理硬件的主内存名字一样，两者可以互相类比，但此处仅是虚拟机内存的一部分）。
工作内存: 每个线程都有一个工作内存，工作内存中主要包括两个部分，一个是属于该线程私有的栈和 对主存部分变量拷贝的寄存器(包括程序计数器PC和cup工作的高速缓存区)。
- 每条线程都有自己的工作内存(Working Memory，又称本地内存.)，线程的工作内存中保存了该线程使用到的变量，该变量是主内存中的共享变量的副本拷贝。
- (工作内存是 JMM 的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。)
二、原子性
原子性在学习线程时讲过，下面来个例子简单回顾一下：
问题提出，两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
static int counter = 0;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
counter++;
}
}, "t1");
Thread t2 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
counter--;
}
}, "t2");
t1.start();
t2.start();
t1.join();
t2.join();
log.debug("{}",counter);
}
2.1 问题分析
以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作，要彻底理 解，必须从字节码来进行分析。
例如对于 i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令
getstatic i //获取静态变量i的值
iconst_1 //准备常量1
iadd //自增
putstatic i //将修改后的值存入静态变量i
而对应 i-- 也是类似
getstatic i //获取静态变量i的值
iconst_1 //java准备常量1
isub //自减
putstatic i //将修改后的值存入静态变量i
而 Java 的内存模型如下，完成静态变量的自增，自减需要在主存和工作内存中进行数据交换
如果是单线程以上 8 行代码是顺序执行（不会交错）没有问题：
但多线程下这 8 行代码可能交错运行：
出现负数的情况：
出现正数的情况：
2.2 解决方法
synchronized （同步关键字）
语法
synchronized( 对象 ) {
要作为原子操作代码
}
用 synchronized 解决并发问题：
static int counter = 0;
static Object obj = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
synchronized (obj) {
counter++;
}
}
}, "t1");
Thread t2 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
synchronized (obj) {
counter--;
}
}
}, "t2");
t1.start();
t2.start();
t1.join();
t2.join();
log.debug("{}",counter);
}
如何理解呢：你可以把 obj 想象成一个房间，线程 t1，t2 想象成两个人。当线程 t1 执行到 synchronized(obj) 时就好比 t1 进入了这个房间，并反手锁住了门，在门内执行count++ 代码。
这时候如果 t2 也运行到了 synchronized(obj) 时，它发现门被锁住了，只能在门外等待。
当 t1 执行完 synchronized{} 块内的代码，这时候才会解开门上的锁，从 obj 房间出来。t2 线程这时才可以进入 obj 房间，反锁住门，执行它的 count-- 代码。
注意：上例中 t1 和 t2 线程必须用 synchronized 锁住同一个 obj 对象，如果 t1 锁住的是 m1 对象，t2 锁住的是 m2 对象，就好比两个人分别进入了两个不同的房间，没法起到同步的效果。
三、可见性
3.1 退不出的循环
先来看一个现象，main线程对run变量的修改对于t线程不可见，导致了 t 线程无法停止
static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(()->{
while(run){
// ....
}
});
t.start();
Thread.sleep(1000);
run = false; // 线程t不会如预想的停下来
}
原因:
- 初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存
- 因为 t 线程要频繁从主内存中读取 run 的值，JIT（Just-In-Time Compiler） 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率
在Java编程语言和环境中，即时编译器（JIT compiler，just-in-time compiler）是一个把Java的字节码（包括需要被解释的指令的程序）转换成可以直接发送给处理器的指令的程序。当你写好一个Java程序后，源语言的语句将由Java编译器编译成字节码，而不是编译成与某个特定的处理器硬件平台对应的指令代码（比如，Intel的Pentium微处理器或IBM的System/390处理器）。字节码是可以发送给任何平台并且能在那个平台上运行的独立于平台的代码。
- 在1 秒后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量 的值，结果永远是旧值
3.2 解决方法
volatile（易变关键字）
volatile 可以认为是一个轻量级的锁，被 volatile 修饰的变量，汇编指令会存在于一个"lock"的前缀。在CPU层面与主内存层面，通过缓存一致性协议，加锁后能够保证写的值同步到主内存，使其他线程能够获得最新的值。
//易变关键字，volatile修饰的变量就不可以去缓存中读取了，只能去主内存读取
volatile static boolean run = true;
- 编写Java程序中，JVM为了提高程序的执行效率，会对我们的程序进行优化，把经常需要被访问的变量存储在我们的缓存当中（即存到CPU寄存器中），而避免直接去内存里读，cpu访问内存的数据，需要通过总线发送指令给内存，这个速度远比不让我们的cpu在我们的寄存器里直接读取数据，可以大大的提高我们程序的运行效率，但是当遇到多线程的情况，变量的值可能已经被别的线程改变了，而该缓存却无法察觉内存中的变化，从而造成我们的线程读取的数据跟内存里的数据是不一致的（脏数据）
- 它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存
- 但是volatile并不能保证我们操作的一个原子性，所以，他是不能取代我们的synchronized的，而且会阻止编译器对我们的程序进行优化，除非很有必要，不然就要避免使用volatile这个关键字
- 在多线程操作中，保证变量得可见性，避免多线程操作下读取到脏数据
synchronized同步代码块
static boolean run = true;
//锁对象
final static Object lock = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(()->{
while(true){
//JMM中，synchronized规定，线程在加锁时，先清空工作内存
// ->在主内存中拷贝最新变量的副本到工作内存——>执行完代码——>将更改后的共享变量的值刷新到主存中——>释放互斥锁
synchronized(lock){
if(!run){
break;
}
}
}
});
t.start();
sleep(1);
synchronized(lock){
run = false; // 线程t不会如预想的停下来
}
}
3.3 可见性 vs 原子性
前面例子体现的实际就是可见性，它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性，适用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
putstatic run // 线程 main 修改 run 为 false， 仅此一次
getstatic run // 线程 t 获取 run false
比较一下之前我们讲线程安全时举的例子(原子性)：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错，所以volatile只能保证可见性、有序性，原子性就用synchronized、reentrantlock
// 假设i的初始值为0
getstatic i // 线程2-获取静态变量i的值 线程内i=0
getstatic i // 线程1-获取静态变量i的值 线程内i=0
iconst_1 // 线程1-准备常量1
iadd // 线程1-自增 线程内i=1
putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
iconst_1 // 线程2-准备常量1
isub // 线程2-自减 线程内i=-1
putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1
synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是synchronized 是属于重量级操作，性能相对更低
如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到 对 run 变量的修改了，想一想为什么？ => 查阅 System.out.println()源代码
因为println方法里面有
synchronized修饰。还有那个等烟的示例, 为啥没有出现可见性问题?和synchrozized是一个道理。
3.4 volatile优化两阶段终止
我们在执行线程一时，想要终止线程二，这是就需要使用interrupt方法来优雅的停止线程二。这是我们之前的做法
https://www.cnblogs.com/wkfvawl/p/15406958.html#scroller-23
public class Test13 {
public static void main(String[] args) throws InterruptedException {
Monitor monitor = new Monitor();
monitor.start();
Thread.sleep(3500);
monitor.stop();
}
}
class Monitor {
Thread monitor;
/**
* 启动监控器线程
*/
public void start() {
//设置线控器线程，用于监控线程状态
monitor = new Thread() {
@Override
public void run() {
//开始不停的监控
while (true) {
//判断当前线程是否被打断了
if(Thread.currentThread().isInterrupted()) {
System.out.println("处理后续任务");
//终止线程执行
break;
}
System.out.println("监控器运行中...");
try {
//线程休眠
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
//如果是在休眠的时候被打断，不会将打断标记设置为true，这时要重新设置打断标记
Thread.currentThread().interrupt();
}
}
}
};
monitor.start();
}
/**
* 用于停止监控器线程
*/
public void stop() {
//打断线程
monitor.interrupt();
}
}
缺点是必须时刻关注InterruptedExceptio，发生 InterruptedExceptio时重新设置打断标记，很容易遗漏，如果不能重新设置好打断标记，进不了if块退出。
使用volatile关键字来实现两阶段终止模式
/*
设置了一个共享变量作为，打断标记
因为多个线程操作共享变量，需要明确变量的可见性，所以加volatile
*/
public class Demo7 {
private Thread monitor; //监控线程
private volatile boolean stop = false; //停止标记
//启动监控线程
public void start() {
monitor = new Thread(() -> {
while (true) {
Thread current = Thread.currentThread();
//是否被打断
if (stop) {
Log.debug("料理后事");
break;
}
try {
Thread.sleep(1000); //情况1
log.debug("执行监控记录"); //情况2
} catch (InterruptedException e) {
e.printStackTrace();
//重新设置打断标记(因为sleep状态下打断会重置标记状态)
current.interrupt();
}
}
});
monitor.start();
}
//停止监控线程
public void stop(){
stop = true;
}
}
3.5 模式之 Balking
前言：对比上边代码，若一个线程对象，执行了两次start（t1.start();t1.start();），那么它执行的流程自然也是双倍且重复的
而监控线程只需要一个就行，为了保证某个方法只执行一次，使用Balking模式。
Balking （犹豫）模式用在 一个线程发现另一个线程或本线程已经做了某一件相同的事，那么本线程就无需再做了，直接结束返回。有点类似于单例模式。
@Slf4j(topic = "c.Test1")
public class TestBalking {
public static void main(String[] args) throws InterruptedException {
Monitor monitor = new Monitor();
monitor.start();
monitor.start();
monitor.start();
Sleeper.sleep(3.5);
monitor.stop();
}
}
@Slf4j(topic = "c.Monitor")
class Monitor {
Thread monitor;
//设置标记，用于判断是否被终止了
private volatile boolean stop = false;
//设置标记，用于判断是否已经启动过了
private boolean starting = false;
/**
* 启动监控器线程
*/
public void start() {
//上锁，避免多线程运行时出现线程安全问题
synchronized (this) {
if (starting) {
//已被启动，直接返回
return;
}
//启动监视器，改变标记
starting = true;
}
//设置线控器线程，用于监控线程状态
monitor = new Thread(() -> {
//开始不停的监控
while (true) {
if(stop) {
log.debug("处理后续儿事");
break;
}
log.debug("监控器运行中...");
try {
//线程休眠
Thread.sleep(1000);
} catch (InterruptedException e) {
log.debug("被打断了...");
}
}
});
monitor.start();
}
/**
* 用于停止监控器线程
*/
public void stop() {
//打断线程
stop = true;
monitor.interrupt();
}
}
运行可以看到，只有一个线程，日志信息隔一秒打印一次
对比一下保护性暂停模式：保护性暂停模式用在一个线程等待另一个线程的执行结果，当条件不满足时线程等待
四、有序性
4.1 指令重排
JVM会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码
static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...;
j = ...;
可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。所以，上面代码真正执行时，既可以是
i = ...;
j = ...;
也可以是
j = ...;
i = ...;
这种特性称之为『指令重排』，多线程下『指令重排』会影响正确性。为什么要有重排指令这项优化呢？从 CPU执行指令的原理来理解一下吧
4.2 指令级并行原理
目的：掌握 指令级并行 是分阶段，分工是提升效率的思想
现代 CPU 支持多级指令流水线，例如支持同时执行 取指令 - 指令译码 - 执行指令 - 内存访问 - 数据写回 的处理器，就可以称之为五级指令流水线。这时 CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一 条执行时间长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令地吞吐率。
大多数处理器包含多个执行单元，并不是所有计算功能都集中在一起，可以再细分为整数运算单元、浮点数运算单元等，这样可以把多条指令也可以做到并行获取、译码等，CPU 可以在一个时钟周期内，执行多于一条指令，IPC>1
在多线程环境下，指令重排序可能导致出现意料之外的结果
4.3 指令重排示例
4.3.1 诡异的结果
int num = 0;
boolean ready = false;
// 线程1 执行此方法
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
// 线程2 执行此方法
public void actor2(I_Result r) {
num = 2;
ready = true;
}
I_Result 是一个对象，有一个属性 r1 用来保存结果；问，可能的结果有几种？
有人会这么分析
- 情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
- 情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
- 情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）
但我告诉你，结果还有可能是 0
这种情况下是：线程2执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2
这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：
4.3.2 实操测试
项目终端下输入：
mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=cn.itcast -
DartifactId=ordering -Dversion=1.0
创建 maven 项目，提供如下测试类
@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")//感兴趣的输出
@State
public class ConcurrencyTest {
int num = 0;
boolean ready = false;
@Actor
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
@Actor
public void actor2(I_Result r) {
num = 2;
ready = true;
}
}
执行
mvn clean install
java -jar target/jcstress.jar
会输出我们感兴趣的结果，摘录其中一次结果：
*** INTERESTING tests
Some interesting behaviors observed. This is for the plain curiosity.
2 matching test results.
[OK] test.ConcurrencyTest
(JVM args: [-XX:-TieredCompilation])
Observed state Occurrences Expectation Interpretation
0 1,729 ACCEPTABLE_INTERESTING !!!!
1 42,617,915 ACCEPTABLE ok
4 5,146,627 ACCEPTABLE ok
[OK] test.ConcurrencyTest
(JVM args: [])
Observed state Occurrences Expectation Interpretation
0 1,652 ACCEPTABLE_INTERESTING !!!!
1 46,460,657 ACCEPTABLE ok
4 4,571,072 ACCEPTABLE ok
可以看到，出现结果为 0 的情况有 652 次，虽然次数相对很少，但毕竟是出现了
- 指令重排序操作不会对存在数据依赖关系的操作进行重排序。比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。
- 重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变。 比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系，所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。
指令重排序 在 单线程模式下是一定会保证最终结果的正确性， 但是在多线程环境下，问题就出来了。
解决方法：volatile 修饰的变量，可以禁用指令重排
使用
synchronized并不能解决有序性问题，但是如果是该变量整个都在synchronized代码块的保护范围内，那么变量就不会被多个线程同时操作，也不用考虑有序性问题！在这种情况下相当于解决了重排序问题！
4.3.3 解决方法
volatile 修饰的变量，可以禁用指令重排
@JCStressTest
@Outcome(id = {"1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")//感兴趣的输出
@State
public class ConcurrencyTest {
int num = 0;
volatile boolean ready = false;//加上 volatile 防止 ready 之前的代码指令重排
@Actor
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
@Actor
public void actor2(I_Result r) {
num = 2;
ready = true;
}
}
结果为
*** INTERESTING tests
Some interesting behaviors observed. This is for the plain curiosity.
0 matching test results
4.4 volatile原理
volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）
- 对 volatile 变量的写指令后会加入写屏障
- 对 volatile 变量的读指令前会加入读屏障
4.4.1 如何保证可见性
- 写屏障（sfence）保证在该屏障之前的，对共享变量的改动，都同步到主存当中
public void actor2(I_Result r) {
num = 2;
ready = true; // ready 是 volatile 赋值带写屏障（ready及之前都被写屏障了）
// 写屏障
}
- 而读屏障（lfence）保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据
public void actor1(I_Result r) {
// 读屏障
// ready 是 volatile 读取值带读屏障
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
4.4.2 如何保证有序性
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
public void actor2(I_Result r) {
num = 2;
ready = true; // ready 是 volatile 赋值带写屏障
// 写屏障
}
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
public void actor1(I_Result r) {
// 读屏障
// ready 是 volatile 读取值带读屏障
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
还是那句话，volatile不能解决指令交错：
- 写屏障仅仅是保证之后的读能够读到最新的结果，但不能保证读跑到它前面去
- 而有序性的保证也只是保证了本线程内相关代码不被重排序
下图t2线程, 就先读取了i=0, 此时还是会出现指令交错的现象, 可以使用synchronized来解决原子性
4.5 双重检查锁(double-checked locking)
4.5.1 懒汉式单例
之前我整理过懒汉式的单例模式的问题。https://www.cnblogs.com/wkfvawl/p/14755198.html
为了在多线程环境下保护懒汉式，对对象加synchronized 锁
public final class Singleton {
private Singleton() { }
private static Singleton INSTANCE = null;
public static Singleton getInstance() {
/*
多线程同时调用getInstance(), 如果不加synchronized锁, 此时两个线程同时
判断INSTANCE为空, 此时都会new Singleton(), 此时就破坏单例了.所以要加锁,
防止多线程操作共享资源,造成的安全问题
*/
synchronized(Singleton.class) {
if (INSTANCE == null) { // t1
INSTANCE = new Singleton();
}
}
return INSTANCE;
}
}
但上面代码的效率是有问题的, 因为当我们创建了一个单例对象后, 又来一个线程获取到锁了,还是会加锁, 严重影响性能,再次判断INSTANCE==null吗, 此时肯定不为null, 然后就返回刚才创建的INSTANCE。
事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进。我们改成下面这个：
4.5.2 双重检查锁优化
public final class Singleton {
private Singleton() { }
private static Singleton INSTANCE = null;
public static Singleton getInstance() {
if(INSTANCE == null) { // t2
// 首次访问会同步，而之后的使用没有 synchronized
synchronized(Singleton.class) {
if (INSTANCE == null) { // t1
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
以上的实现特点是
- 懒惰实例化
- 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁
- 有隐含的，但很关键的一点：第一个 if 使用了 INSTANCE 变量，是在同步块之外
4.5.3 问题
但在多线程环境下，上面的代码是有问题的，getInstance 方法对应的字节码为：
0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37 // 判断是否为空
// ldc是获得类对象
6: ldc #3 // class cn/itcast/n5/Singleton
// 复制操作数栈栈顶的值放入栈顶, 将类对象的引用地址复制了一份
8: dup
// 操作数栈栈顶的值弹出，即将对象的引用地址存到局部变量表中
// 将类对象的引用地址存储了一份，是为了将来解锁用
9: astore_0
10: monitorenter
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
// 新建一个实例
17: new #3 // class cn/itcast/n5/Singleton
// 复制了一个实例的引用
20: dup
// 通过这个复制的引用调用它的构造方法
21: invokespecial #4 // Method "<init>":()V
// 最开始的这个引用用来进行赋值操作
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn
其中
- 17 表示创建对象，将对象引用入栈 // new Singleton
- 20 表示复制一份对象引用 // 引用地址
- 21 表示利用一个对象引用，调用构造方法
- 24 表示利用一个对象引用，赋值给 static INSTANCE
可能jvm 会优化为：先执行 24(赋值)，再执行 21(构造方法)。如果两个线程 t1，t2 按如下时间序列执行：
通过上面的字节码发现, 这一步INSTANCE = new Singleton();操作不是一个原子操作, 它分为21, 24两个指令, 此时可能就会发生指令重排的问题：
- 关键在于 0: getstatic 这行代码在 monitor 控制之外，它就像之前举例中不守规则的人，可以越过 monitor 读取 INSTANCE 变量的值
- 这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例 对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排。
- 注意在 JDK 5 以上的版本的 volatile 才会真正有效
4.5.4 volatile解决方案
public final class Singleton {
private Singleton() { }
private static volatile Singleton INSTANCE = null;
public static Singleton getInstance() {
// 实例没创建，才会进入内部的 synchronized代码块
if (INSTANCE == null) {
synchronized (Singleton.class) { // t2
// 也许有其它线程已经创建实例，所以再判断一次
if (INSTANCE == null) { // t1
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}
字节码上看不出来 volatile 指令的效果
// -------------------------------------> 加入对 INSTANCE 变量的读屏障
0: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
3: ifnonnull 37
6: ldc #3 // class cn/itcast/n5/Singleton
8: dup
9: astore_0
10: monitorenter -----------------------> 保证原子性、可见性
11: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
14: ifnonnull 27
17: new #3 // class cn/itcast/n5/Singleton
20: dup
21: invokespecial #4 // Method "<init>":()V
24: putstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
// -------------------------------------> 加入对 INSTANCE 变量的写屏障
27: aload_0
28: monitorexit ------------------------> 保证原子性、可见性
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #2 // Field INSTANCE:Lcn/itcast/n5/Singleton;
40: areturn
如上面的注释内容所示，读写 volatile 变量时会加入内存屏障（Memory Barrier（Memory Fence）），保证下面两点：
- 可见性
- 写屏障（sfence）保证在该屏障之前的 t1 对共享变量的改动，都同步到主存当中
- 而读屏障（lfence）保证在该屏障之后 t2 对共享变量的读取，加载的是主存中最新数据
- 有序性
- 写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
- 读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前
- 更底层是读写变量时使用 lock 指令来多核 CPU 之间的可见性与有序性
加上volatile之后, 保证了指令的有序性, 不会发生指令重排, 21就不会跑到24之后执行了
- synchronized 既能保证原子性、可见性、有序性，其中有序性是在该共享变量完全被synchronized 所接管（包括共享变量的读写操作），上面的例子中synchronized 外面的 if (INSTANCE == null) 中的INSTANCE读操作没有被synchronized 接管，因此无法保证INSTANCE共享变量的有序性（即不能防止指令重排）。
- 对共享变量加volatile关键字见性和有序性，但是不能保证原子性（即不能防止指令交错）。
4.6 happens-before规则
happens-before 规定了对共享变量的写操作,对其它线程的读操作可见，它是可见性与有序性的一套规则总结。抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变量的读可见。
下面说的变量都是指 成员变量或静态成员变量
方式一
线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的 读可见
synchronized锁, 保证了可见性
static int x;
static Object m = new Object();
new Thread(()->{
synchronized(m) {
x = 10;
}
},"t1").start();
new Thread(()->{
synchronized(m) {
System.out.println(x);
}
},"t2").start();
方式二
线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
volatile修饰的变量, 通过写屏障, 共享到主存中, 其他线程通过读屏障, 读取主存的数据
volatile static int x;
new Thread(()->{
x = 10;
},"t1").start();
new Thread(()->{
System.out.println(x);
},"t2").start();
方式三
线程 start() 前对变量的写，对该线程开始后对该变量的读可见
线程还没启动时, 修改变量的值, 在启动线程后, 获取的变量值, 肯定是修改过的
volatile static int x;
new Thread(()->{
x = 10;
},"t1").start();
new Thread(()->{
System.out.println(x);
},"t2").start();
方式四
线程结束前 对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）
主线程获取的x值, 是线程执行完对x的写操作之后的值。
static int x;
Thread t1 = new Thread(()->{
x = 10;
},"t1");
t1.start();
t1.join();
System.out.println(x);
方式五
线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后, 对变量的读可见（通过 t2.interrupted 或 t2.isInterrupted）
static int x;
public static void main(String[] args) {
Thread t2 = new Thread(()->{
while(true) {
if(Thread.currentThread().isInterrupted()) {
System.out.println(x); // 10, 打断了, 读取的也是打断前修改的值
break;
}
}
},"t2");
t2.start();
new Thread(()->{
sleep(1);
x = 10;
t2.interrupt();
},"t1").start();
while(!t2.isInterrupted()) {
Thread.yield();
}
System.out.println(x); // 10
}
方式六
- 对变量默认值（0，false，null）的写，对其它线程对该变量的 读可见 (最基本)
- 具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z ，配合 volatile 的防指令重排，有下面的例子
volatile static int x;
static int y;
new Thread(()->{
y = 10;
x = 20;
},"t1").start();
new Thread(()->{
// x=20 对 t2 可见, 同时 y=10 也对 t2 可见
System.out.println(x);
},"t2").start();
- 因为x加了volatile, 所以在volatile static int x 代码的上面添加了读屏障, 保证读到的x和y的变化是可见的(包括y, 只要是读屏障下面都OK); 通过传递性, t2线程对x,y的写操作, 都是可见的
总结
volatile主要用在一个线程改,多个线程读时的来保证可见性，和double-checked locking模式中保证synchronized代码块外的共享变量的指令重排序问题
