【三】回避不了的面试问题 ==＞ volatile

【三】回避不了的面试问题 ==> volatile

如果面试问到多线程高并发方面的话必然会问到volatile，很多小伙伴对于volatile的认知可能还不够清晰，今天我们一起来彻底的搞定它。

我们先来看一个段代码，了解一个奇怪的现象

public class VolatileTest {
    private static boolean flag = false;

    public static void main(String[] args) {
        A a = new A();
        a.start();
        while (true) {
            if (flag) {
                System.out.println("程序启动成功！");
            }
        }
    }
    static class A extends Thread {
        @Override
        public void run() {
            try {
                Thread.sleep(1000);
            } catch (Exception e) {
                e.printStackTrace();
            }
            flag = true;
            System.out.println("修改后,flag:" + flag);
        }
    }
}

如果你尝试运行这个代码，你会发现你拥有也不会输出程序启动成功!，但是按照代码逻辑来说我们的a.start中已经吧flag修改为true了啊，为什么会出现这样的情况呢，接下来我们就一起解密这个问题吧

一、JMM

JMM(Java Memory Mode): Java内存模型，是java虚拟机规范中所定义的一种内存模型，和JVM不是同一个东西，JVM是整个计算机虚拟模型，所以JMM是隶属于JVM的。

相信很多非科班的小伙伴，或者曾经翘课的童鞋们对于计算机模型还不是很熟悉吧，那我们先科普一下现代计算机的内存模型吧。

现代计算机的内存模型

在计算机早期阶段cpu和内存的速度是差不多的，但是在现在计算机中，cpu的指令速度和内存的存取速度相差了几个数量级，由于计算机的存储设备与处理器的运算速度的差距太大，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲。

将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（CacheCoherence）。

在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（MainMemory）。

了解到这里后我们就可以接着聊下JMM了

JMM

Java内存模型(JavaMemoryModel)描述了Java程序中各种变量(线程共享变量)的访问规则，以及在JVM中将变量，存储到内存和从内存中读取变量这样的底层细节。

JMM有以下规定：

所有的共享变量都存储于主内存，这里所说的变量指的是实例变量和类变量，不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。

每一个线程还存在自己的工作内存，线程的工作内存，保留了被线程使用的变量的工作副本。

线程对变量的所有的操作(读，取)都必须在工作内存中完成，而不能直接读写主内存中的变量。

不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存中转来完成。

本地内存和主内存的关系：

正是因为这样的机制，才导致了可见性问题的存在，那我们就讨论下可见性的解决方案。

二、可见性的解决方案

加锁

public static void main(String[] args) {
    A a = new A();
    a.start();
    while (true) {
        synchronized (a) {
            if (flag) {
                System.out.println("程序启动成功!");
                flag = false;
            }
        }
    }
}

为啥加锁可以解决可见性问题呢？

因为某一个线程进入synchronized代码块前后，线程会获得锁，清空工作内存，从主内存拷贝共享变量最新的值到工作内存成为副本，执行代码，将修改后的副本的值刷新回主内存中，线程释放锁。

而获取不到锁的线程会阻塞等待，所以变量的值肯定一直都是最新的。

Volatile修饰共享变量

public class VolatileTest {
    private static volatile boolean flag = false;

    public static void main(String[] args) {
        A a = new A();
        a.start();
        while (true) {
            if (flag) {
                System.out.println("程序启动成功!");
                flag = false;
            }
        }
    }
}

相比于文章开头的代码 貌似就只是在flag属性钱添加了volatile，为什么就可以了呢？

Volatile做了啥？

每个线程操作数据的时候会把数据从主内存读取到自己的工作内存，如果他操作了数据并且写回了主内存，他其他已经读取的线程的变量副本就会失效了，需要读数据进行操作又要再次去主内存中读取了。

volatile保证不同线程对共享变量操作的可见性，也就是说一个线程修改了volatile修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。

是不是看着加一个关键字很简单，但实际上他在背后含辛茹苦默默付出了不少，我从计算机层面的缓存一致性协议解释一下这些名词的意义。

之前我们说过当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，举例说明变量在多个CPU之间的共享。

如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？

为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI（IllinoisProtocol）、MOSI、Synapse、Firefly及DragonProtocol等。

聊一下Intel的MESI吧

三、MESI（缓存一致性协议）

当CPU写数据时，如果发现操作的变量是共享变量，即在其他CPU中也存在该变量的副本，会发出信号通知其他CPU将该变量的缓存行置为无效状态，因此当其他CPU需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

至于是怎么发现数据是否失效呢？利用的是嗅探。

四、嗅探

每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

嗅探的缺点不知道大家发现了没有？

总线风暴

由于Volatile的MESI缓存一致性协议，需要不断的从主内存嗅探和cas不断循环，无效交互会导致总线带宽达到峰值。

所以不要大量使用Volatile，至于什么时候去使用Volatile什么时候使用锁，根据场景区分。

我们再来聊一下指令重排序的问题

五、禁止指令重排序

什么是重排序?

为了提高性能，编译器和处理器常常会对既定的代码执行顺序进行指令重排序。

重排序的类型有哪些呢？源码到最终执行会经过哪些重排序呢？

一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标，而进行奋斗：在不改变程序执行结果的前提下，尽可能提高执行效率。

JMM对底层尽量减少约束，使其能够发挥自身优势。

因此，在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排序。

一般重排序可以分为如下三种：

• 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序;
• 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序;
• 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。

这里还得提一个概念，as-if-serial。

as-if-serial

不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

并发下重排序带来的问题

public class VolatileTest02 {
    private boolean flag = false;
    private int a = 0;

    public void init() {
        a = 1;//操作1
        flag = true;//操作2
    }

    public void use() {
        if (flag) {//操作3
            int b = a * a;//操作4
        }
    }
}

这里假设有两个线程分别执行init和use方法，其中线程A先执行init方法，接着线程B执行use方法,

由于操作1和操作2没有数据依赖关系，编译器和处理器可以对这两个操作重排序；同样，操作3和操作4没有数据依赖关系，编译器和处理器也可以对这两个操作重排序。

让我们先来看看，操作1和操作2做了重排序。程序执行时，线程A首先写标记变量flag，随后线程B读这个变量。由于条件判断为真，线程B将读取变量a。此时，变量a还没有被线程A写入，这时就会发生错误！

在程序中，操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算a*a，然后把计算结果临时保存到一个名为重排序缓冲（Reorder Buffer，ROB）的硬件缓存中。当操作3的条件判断为真时，就把该计算结果写入变量i中。猜测执行实质上对操作3和4做了重排序，问题在于这时候，a的值还没被线程A赋值。在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。

那Volatile是怎么保证不会被执行重排序的呢？

六、内存屏障——禁止重排序

java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。

内存屏障分为两种

• Load Barrier 读屏障
• Store Barrier 写屏障

内存屏障的两个作用

• 阻止屏障两侧的指令重排序
• 写的时候，强制把缓冲区/高速缓存中的数据写回主内存，并让缓冲中的数据失效；读的时候直接从主内存中读取

对于Load Barrier来说，在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制从新从主内存加载数据

对于Store Barrier来说，在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见

java的内存屏障通常所谓的四种即LoadLoad、StoreStore、LoadStore、StoreLoad实际上也是上述两种的组合，完成一系列的屏障和数据同步功能

• LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕。
• StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
• LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
• StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能

volatile与内存屏障

• 在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障；
• 在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障；

所以volatile防止了指令的重排序(保证有序性)和内存的一致性(保证可见性)

当然是用synchronized或者Lock给代码加锁，也是可以保证有序性与可见性的

从JDK5开始，提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。

happens-before

如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。

无法保证原子性

对任意单个volatile变量的读 /写具有原子性， 写具有原子性， 但类似于 i++这种复合操作不具有原子性。

因为i++这样的操作实际上底层实现： 是 1、int temp = i; 2、 i = i + 1; 3、i = temp

要解决也简单，要么用原子类，比如AtomicInteger，要么加锁。

总结

由于 volatile仅仅保证对单个volatile变量的读 /写具有原子性， 而锁的 互斥执行特性可以确保对整个临界区代码的执行具有原子性。 在功能上，锁比 volatile更强 大；在可伸缩性和执行能上， volatile更有优势 。

1. volatile修饰符适用于以下场景：某个属性被多个线程共享，其中有一个线程修改了此属性，其他线程可以立即得到修改后的值，比如booleanflag;或者作为触发器，实现轻量级同步。
2. volatile属性的读写操作都是无锁的，它不能替代synchronized，因为它没有提供原子性和互斥性。因为无锁，不需要花费时间在获取锁和释放锁_上，所以说它是低成本的。
3. volatile只能作用于属性，我们用volatile修饰属性，这样compilers就不会对这个属性做指令重排序。
4. volatile提供了可见性，任何一个线程对其的修改将立马对其他线程可见，volatile属性不会被线程缓存，始终从主 存中读取。
5. volatile提供了happens-before保证，对volatile变量v的写入happens-before所有其他线程后续对v的读操作。
6. volatile可以使得long和double的赋值是原子的。
7. volatile可以在单例双重检查中实现可见性和禁止指令重排序，从而保证安全性。

--------------最后感谢大家的阅读，愿大家技术越来越流弊！--------------

--------------也希望大家给我点支持，谢谢各位大佬了！！！--------------