大家好，又见面了，我是你们的朋友全栈君。
一、Java的内存模型(JMM)
在仔细讲解Java的volatile关键字之前有必要先了解一下【Java的内存模型】
Java的内存模型简称JMM(Java Memory Model)，是Java虚拟机所定义的一种抽象规范用来屏蔽【不同硬件】和【操作系统】的【内存访问差异】。
让Java程序在各种平台下都能达到一致的内存访问效果。
Java内存模型长成什么样子呢？ 就是下图的样子：
这里需要解释几个概念：
①. 主内存（Main Memory）
主内存可以简单理解为计算机当中的内存，但又不完全等同。
主内存被所有线程共享，对于一个共享变量（比如静态变量，或是堆内存中的实例）来说，主内存当中存储了它的”本尊”。
②. 工作内存（Working Memory）
工作内存可以理解为计算机当中的CPU高速缓存，但又不完全等同。
每一个线程拥有自己的工作内存，对于一个共享变量来说，工作内存当中存储了它的”副本”。
线程对【共享变量】的所有操作都必须在【工作内存】中进行，不能直接读写【主内存】中的变量。
不同线程之间也无法访问彼此的【工作内存】，【变量值的传递】只能通过【主内存】来进行。
直接操作【主内存】太慢，所以JVM才不得不利用性能较高的【工作内存】。
这里类比一下：CPU、高速缓存、内存 之间的关系
【工作内存】所更新的【变量】并不会立即同步到主内存。
二、Volatile关键字具有的特性
①. volatile关键字具有许多特性，其中最重要的特性就是保证了用volatile修饰的变量对所有线程的可见性。
这里的可见性是什么意思呢？
当一个线程修改了变量的值，新的值会立刻同步到主内存当中。 而其他线程读取这个变量的时候，也会从主内存中拉取最新的变量值。
为什么volatile关键字可以有这样的特性？
因为Java语言的【先行发生原则(happens-before)】
三、什么是先行发生原则（happens-before）？
①. 在计算机科学中，【先行发生原则】是两个事件的结果之间的关系 如果一个事件发生在另一个事件之前，结果必须反映，即使这些事件实际上是乱序执行的（通常是优化程序流程）。
这里所谓的事件，实际上就是各种指令操作，比如读操作、写操作、初始化操作、锁操作等等。
②. 先行发生原则作用于很多场景下，包括同步锁、线程启动、线程终止、volatile。
我们这里只列举出volatile相关的规则：
对于一个volatile变量的写操作先行发生于后面对这个变量的读操作
如果在静态变量s之前加上volatile修饰符： volatile static int s = 0；
线程A执行如下代码： s = 3；
这时候我们引入线程B，执行如下代码： System.out.println(“s=” s);
当线程A先执行的时候，把s = 3写入主内存的事件必定会先于读取s的事件。所以线程B的输出一定是s = 3。
四、Volatile只能保证变量的【可见性】，并不能保证变量的【原子性】
代码语言：javascript复制 public class VolatileTest {
public volatile static int count = 0;
public static void main(String [] args){
//开启10个线程
for(int i = 0;i < 10; i ){
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//每个线程中让count的值自增100次
for(int j = 0;j < 100;j ){
count ;
}
}
}).start();
}
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("count= " count);
}
}这段代码是什么意思呢？
很简单，开启10个线程，每个线程当中让静态变量count自增100次。执行之后会发现，最终count的结果值未必是1000，有可能小于1000。
使用volatile修饰的变量，为什么并发自增的时候会出现这样的问题呢？
这是因为count 这一行代码本身并不是原子性操作，在字节码层面可以拆分成如下指令： getstatic //读取静态变量（count） iconst_1 //定义常量1 iadd //count增加1 putstatic //把count结果同步到主内存
虽然每一次执行 getstatic 的时候，获取到的都是主内存的最新变量值，但是进行iadd的时候，由于并不是原子性操作，其他线程在这过程中很可能让count自增了很多次。
这样一来本线程所计算更新的是一个陈旧的count值，自然无法做到线程安全：
五、什么时候适合用Volatile呢？
1、运行结果并不依赖【变量的当前值】，或者能够确保只有单一的线程修改变量的值。
这个很好理解，就是上面的代码例子。
2、变量不需要与其他的状态变量共同参与不变约束。
这个是什么意思呢？可以看看下面这个场景：
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对【指令的重排序】影响
1）什么是【指令重排序】？
指令重排序是指： JVM在编译Java代码的时候，或者CPU在执行JVM字节码的时候，对现有的【指令顺序】进行【重新排序】。
2）指令重排序的【目的】？
目的：为了在不改变程序执行结果的前提下，优化程序的运行效率。
需要注意的是，这里所说的不改变执行结果，指的是【单线程】下的程序执行结果。
3）然而，指令重排序是一把双刃剑，虽然优化了程序的执行效率，但是在某些情况下，会影响到【多线程】的执行结果。
我们来看看下面的例子：
boolean contextReady = false;
在线程A中执行:
context = loadContext();
contextReady = true;
在线程B中执行:
while( ! contextReady ){
sleep(200);
}
doAfterContextReady (context);
以上程序看似没有问题。线程B循环等待上下文context的加载，一旦context加载完成，contextReady == true的时候，才执行doAfterContextReady 方法。
但是，如果线程A执行的代码发生了指令重排，初始化和contextReady的赋值交换了顺序：
boolean contextReady = false;
在线程A中执行:
contextReady = true;
context = loadContext();
在线程B中执行:
while( ! contextReady ){
sleep(200);
}
doAfterContextReady (context);
这个时候，很可能context对象还没有加载完成，变量contextReady 已经为true，线程B直接跳出了循环等待，开始执行doAfterContextReady 方法，结果自然会出现错误。
需要注意的是，这里java代码的重排只是为了简单示意，真正的指令重排是在【字节码指令层面】。
七、指令重排序解决方法？
【内存屏障】
1）什么是内存屏障？
内存屏障（Memory Barrier）是一种CPU指令
内存屏障也称为内存栅栏或栅栏指令，是一种屏障指令，它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。
这通常意味着在屏障之前发布的操作被保证在屏障之后发布的操作之前执行。
内存屏障共分为四种类型：
1） LoadLoad屏障：
抽象场景：Load1; LoadLoad; Load2
Load1 和 Load2 代表两条读取指令。在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
2）StoreStore屏障：
抽象场景：Store1; StoreStore; Store2
Store1 和 Store2代表两条写入指令。在Store2写入执行前，保证Store1的写入操作对其它处理器可见
3）LoadStore屏障：
抽象场景：Load1; LoadStore; Store2
在Store2被写入前，保证Load1要读取的数据被读取完毕。
4）StoreLoad屏障：
抽象场景：Store1; StoreLoad; Load2
在Load2读取操作执行前，保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是四种屏障中最大的。
八、内存屏障在Java代码中怎么使用？
这就涉及到了【Volatile】，来看看它究竟为我们做了些什么。
volatile做了什么？
在一个变量被Volatile修饰后，JVM会为我们做2件事：
1. 在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障。
2. 在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障。
或许这样说有些抽象，我们看一看刚才线程A代码的例子：
boolean contextReady = false;
在线程A中执行:
context = loadContext();
contextReady = true;
我们给contextReady 增加volatile修饰符，会带来什么效果呢？
由于加入了StoreStore屏障，屏障上方的普通写入语句 context = loadContext() 和屏障下方的volatile写入语句 contextReady = true 无法交换顺序，从而 成功阻止了指令重排序。
那么内存屏障和之前所介绍的Java语言happens-before规则之间，是什么样的关系呢？
happens-before是JSR-133规范之一，内存屏障是CPU指令。
可以简单认为前者是最终目的，后者是实现手段。
九、总结
1. Volatile特性之一：
保证【变量】在【多线程】之间的【可见性】。
可见性的保证是基于CPU的内存屏障指令，被JSR-133抽象为happens-before原则。
2. Volatile特性之二：
阻止编译时和运行时的指令重排。
编译时JVM编译器遵循【内存屏障】的约束
运行时依靠【CPU屏障指令】来阻止重排。
几点补充：
1. 关于volatile的介绍，本文很多内容来自《深入理解Java虚拟机》这本书。有兴趣的同学可以去看看。
2. 在使用volatile引入内存屏障的时候，普通读、普通写、volatile读、volatile写会排列组合出许多不同的场景。我们这里只简单列出了其中一种，有兴趣的同学可以查资料进一步学习其他阻止指令重排的场景。
3.volatile除了保证可见性和阻止指令重排，还解决了long类型和double类型数据的8字节赋值问题。这个特性相对简单，本文就不详细描述了。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/157712.html原文链接：https://javaforall.cn
