1、相关了解
1.1.现代计算机的内存模型
其实早期计算机中cpu和内存的速度是差不多的，但在现代计算机中，cpu的指令速度远超内存的存取速度，由于计算机的储存设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的 高速缓存(Cach) 来作为内存与处理器之间的缓冲。
将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了。
基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入一个新的问题：缓存一致性(CacheCoherence)。
在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存(MainMemory)。
![]()
1.2.JMM(JavaMemoryModel)
JMM：Java 内存模型，是java虚拟机规范中所定义的一种内存模型，Java 内存模型是标准化的，屏蔽掉了底层不同计算机的区别。描述了Java程序中各种变量(线程共享变量)的访问规则，以及在JVM中将变量，储存到内存和从内存中读取变量这样的底层细节。
1.2.1JMM有以下规定
所有的共享变量都储存于主内存，这里所说的变量指的是实例变量和类变量，不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。
每一个线程还存在自己的工作内存，线程的工作内容，保留了被线程使用的变量的工作副本。
线程对变量的所有操作(读、取)都必须在工作内存中完成，而不能直接读写主内存中的变量。
不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存中转来完成。
本地内存和主内存的关系：
![]()
正是因为这样的机制，才导致了可见性问题的存在。
2、可见性的解决方案
加锁
/**
* @Author 庭前云落
* @Date 2020/10/1 10:43
* @Description
*/
public class Test {
public static void main(String[] args) {
Tqyl a = new Tqyl();
a.start();
for (; ; ) {
synchronized (a) {
if (a.isFlag()) {
System.out.println("庭前云落");
}
}
}
}
}
2.1.为什么加锁可以解决可见性问题呢?
因为某一个线程进入synchronized代码块前后，线程会获得锁，清空工作内存，从主内存拷贝共享变量最新的值到工作内存成为副本，执行代码，将修改后的副本的值刷新回主内存中，线程释放锁。
而获取不到锁的线程会阻塞等待，所以变量的值肯定一直都是最新的。
2.2.Volatile修饰共享变量
/**
* @Author 庭前云落
* @Date 2020/10/1 10:44
* @Description
*/
public class Tqyl extends Thread {
private volatile boolean flag = false;
public boolean isFlag() {
return flag;
}
@Override
public void run() {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
flag=true;
System.out.println("flag="+flag);
}
}
2.3.Volatile做了什么？
每个线程操作数据的时候会把数据从主内存读取到自己的工作内存，如果它操作了数据并且写回了，其它已经读取的线程的变量副本就会失效了，需要读数据进操作又要再次去主内存中读取了。
volatile保证不同线程对共享变量操作的可见性，也就是说一个线程修改了volatile修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。
之前我们说过当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，举例说明变量在多个CPU之间的共享。
如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？
为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有 MSI、MESI(IllinoisProtocol)、MOSI、Synapse、Firefly及DragonProtocol等。
3、MESI(缓存一致性协议)
当CPU写数据时，如果发现操作的变量是共享变量，即在其它CPU中野存在该变量的副本，会发出信息通知其它CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。
3.1.至于怎么发现数据是否失效呢？
嗅探（窃听网络上流经的数据包）
每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。
4、总线风暴
由于Volatile的MESI缓存一致性协议，需要不断的从主内存嗅探和cas不断循环，无效交互会导致总线带宽达到峰值。
所以不要大量使用Volatile，至于什么时候去使用Volatile什么时候使用锁，根据场景区分。
CAS(Compare-and-Swap)：即比较并替换，是一种实现并发算法时常用到的技术，Java并发包中的很多类都使用了CAS技术。
5、禁止指令重排序
5.1.什么是重排序？
为了提高性能，编译器和处理器常常会对既定的代码执行顺序进行指令重排序。
5.2.重排序的类型有哪些呢？源码到最终执行会经过哪些重排序呢？
![]()
一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标，而进行奋斗：在不改变程序执行结果的前提下，尽可能提高执行效率。
JMM对底层尽量减少约束，使其能够发挥自身优势。
因此，在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排序。
一般重排序可以分为如下三种：
- 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序;
- 指令级并行的重排序。现代化处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序；
- 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和储存操作看上去可能是在乱序执行的。
这里还得提一个概念，as-if-serial。
5.3.as-if-serial
不管怎么重排序，单线程下的执行结果不能被改变。
编译器、runtime和处理器都必须遵守as-if-serial语义。
那Volatile是怎么保证不会被执行重排序的呢？
5.4.内存屏障
java编译器会在生成指令系列时在适当的位置会插入 内存屏障 指令来禁止特定类型的处理器重排序。
为了实现volatile的内存语义，JMM会限制特定类型的编译器和处理器重排序，JMM会针对编译器制定volatile重排序规则表：
![]()
需要注意的是：volatile写是在前⾯和后⾯分别插⼊内存屏障，⽽volatile读操作是在后面插⼊两个内存屏障。
写
![]()
读
![]()
上面的我提过重排序原则，为了提高处理速度，JVM会对代码进行编译优化，也就是指令重排序优化，并发编程下指令重排序会带来一些安全隐患：如指令重排序导致的多个线程操作之间的不可见性。
如果让程序员再去了解这些底层的实现以及具体规则，那么程序员的负担就太重了，严重影响了并发编 程的效率。
从JDK5开始，提出了 happens-before 的概念，通过这个概念来阐述操作之间的内存可⻅性。
5.5.happens-before
如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在 happens-before关系。
volatile域规则：对一个 volatile 域的写操作，happens-before 于任意线程后续对这个volatile域的读。
如果现在我的flag变成了false，那么后面的那个操作，一定要知道我变了。
我们要知道Volatile是没办法保证原子性的，一定要保证原子性，可以使用其他方法。
无法保证原子性
就是一次操作，要么完全成功，要么完全失败。
假设现在有 N 个线程对同一个变量进行累加也是没办法保证结果是对的，因为读写这个过程并不是原子性的。
要解决也简单，要么用原子类，比如 AtomicInteger，要么加锁(记得关注Atomic的底层)
应用
/**
* @Author 庭前云落
* @Date 2020/10/1 11:53
* @Description
*/
public class Singleton {
//可见性和指令重排序都保证
private volatile static Singleton instance = null;
//私有构造
public Singleton() {
}
public static Singleton getInstance(){
//第一重检查锁定
if(instance==null){
//同步锁定代码块
synchronized (Singleton.class){
//第二重检查锁定
if(instance==null){
//注意:非原子操作
instance = new Singleton();
}
}
}
return instance;
}
}
为什么要双重检查？如果不用Volatile会怎么样?
禁止指令重排序的好处。
对象实际上创建对象要经过如下几个步骤：
- 分配内存空间
- 调用构造器，初始化实例
- 返回地址给引用
是可能发生指令重排序的，那有可能构造函数在对象初始化完成前就赋值完成了，在内存里面开辟一片储存区域后直接返回内存的引用，这个时候还没真正的初始化完对象。
但是别的线程去判断 instance!=null，直接拿去用了，其实这个对象是个半成品，那就有空指针异常了。
可见性怎么保证的？
因为可见性，线程A在自己的内存初始化了对象，还没来得及写回主内存，B线程也这么做了，那就创建了多个对象，不是真正意义上单例了。
6、Volatile与Synchronized的区别
volatile只能修饰实例变量和类变量，而synchronized可以修饰方法，以及代码块。
volatile保证数据的可见性，但是不保证原子性(多线程进行写操作，不保证线程安全)；而synchronized是一种排他(互斥)的机制。volatile用于禁止指令重排序：可以解决单例双重检查对象初始化代码执行乱序问题。
volatile 可以看做轻量版的synchronized，volatile不保证原子性，但是如果是对一个共享变量进行多个线程的赋值，而没有其它的操作，那么就可以用 volatile 来代替 synchronized，因为赋值本身就是有原子性的，而 volatile 又保证了可见性，所以就可以保证线程安全了。
7、总结
-
volatile修饰符适用于以下的场景：
某个属性被多个线程共享，其中有一个线程修改了此属性，其它线程可以立即得到修改后的值，比如 booleanflag；或者作为触发器，实现轻量级同步。
-
volatile属性的读写操作都是无锁的，它不能替代synchronized，因为它没有提供原子性和互斥性。因为无锁，不需要花费时间在获取锁和释放锁上，所以说它是低成本的。
-
volatile只能作用于属性，我们用volatile修饰属性，这样compilers就不会对这个属性做指令重排序。
-
volatile提供了可见性，任何一个线程对其的修改将立马对其它线程可见，volatile属性不会被线程缓存，始终从主存中读取。
-
volatile提供了happens-before保证，对volatile变量v的写入happens-before所有其他线程后续对v的读写操作。
-
volatile可以使得long和double的赋值是原子的。
-
volatile可以在单例双重检查中实现可见性和禁止指令重排序，从而保证安全性。
