Volatile

关键词：JMM 并发的三大特性 volatile

一、JMM

要聊volatile，我们首先看看什么是JMM

JMM,即Java内存模型（Java Memory Model）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。

JMM数据同步的八大原子操作

定义

关于主内存与工作内存之间的交互协议，即一个变量如何从主内存拷贝到工作内存。如何从工作内存同步到主内存中的实现细节。java内存模型定义了8种操作来完成，这8种操作每一种都是原子操作。

（1）lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态

（2）unlock(解锁)：作用于主内存的变量,把一个处于锁定状态的变量释放出来,释放后的变量才能被其他线程锁定

（3）read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中,以便随后的load动作使用

（4）load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中

（5）use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎

（6）assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量

（7）store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中,以便随后的write的操作

（8）write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

大致过程：

规则

1、不允许read和load、store和write操作之一单独出现（即不允许一个变量从主存读取了但是工作内存不接受，或者从工作内存发起会写了但是主存不接受的情况），以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其他指令的。
2、不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
4、一个新的变量只能从主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
5、一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
6、如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。
7、如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）。

以上规则可以理解为：

• 线程解锁前，必须把共享变量立刻刷回内存
• 线程加锁前，必须读取主存中的最新值到工作内存中
• 加锁和解锁是同一把锁

二、并发三大特性

原子性

定义：即一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。

注：Java里，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元。可能会出现不同现场读取数值不同的情况，如一个线程读的前32位，另一个线程读的后32位。

可见性

定义：当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。

引出：从JMM模型中可以看出，当多线程操作时可能会出现问题，当某一个线程修改了某个共享变量时，另一个线程也在修改的话，哪一个线程最先修改完，且怎么通知另一个正在修改的线程是一个问题？因为数据同步回主内存是有一定的延迟的。以及指令重排、编译器优化等也可能导致可见性问题。

有序性

定义：指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致。

三、JMM与三大特性

实现原子性

JVM自身提供的对基本数据那些读写操作可保证原子性。synchronized和Lock(保证任一时刻只有一个线程可访问某一处代码)可实现原子性。

实现可见性

volatile关键字可实现可见性（类似通知功能，通知别的线程）。synchronized和Lock也可保证可见性(原子性基础上，释放锁之前会刷新值到内存中)。

实现有序性

volatile关键字可保证一定的有序性(内存屏障、happens-before)。synchronized和Lock也可保证有序性(线程加锁，相当于顺序执行)

四、volatile

1、保证可见性

通过上面的描述我们知道volatile关键字可实现可见性，那么它是怎么实现的呢

import java.util.concurrent.TimeUnit;

public class JMMTest01 {
    private static int num = 0;

    public static void main(String[] args) {
        new Thread(()-> {
            while(num == 0){

            }
        }).start();

        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        num = 1;
        System.out.println(num);
    }
}

我们看看这段程序经历了什么

由上图可知，线程A没有及时看见线程B对于num值的更改，num值仍为0，程序进入了死循环

加了volatile关键字之后，保证了可见性，相当于告诉了线程A主内存的值已经发生了变化

import java.util.concurrent.TimeUnit;

public class JMMTest01 {
    private volatile static int num = 0;

    public static void main(String[] args) {
        new Thread(()-> {
            while(num == 0){

            }
        }).start();

        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        num = 1;
        System.out.println(num);
    }
}

MESI缓存一致性协议

volatile可见性是通过汇编加上Lock前缀指令，触发底层的MESI缓存一致性协议来实现的。当然这个协议有很多种，不过最常用的就是MESI。MESI表示四种状态，如下所示：

状态	描述
M 修改（Modified）	此时缓存行中的数据与主内存中的数据不一致，数据只存在于本工作内存中。其他线程从主内存中读取共享变量值的操作会被延迟执行，直到该缓存行将数据写回到主内存后
E 独享（Exclusive）	此时缓存行中的数据与主内存中的数据一致，数据只存在于本工作内存中。此时会监听其他线程读主内存中共享变量的操作，如果发生，该缓存行需要变成共享状态
S 共享（Shared）	此时缓存行中的数据与主内存中的数据一致，数据存在于很多工作内存中。此时会监听其他线程使该缓存行无效的请求，如果发生，该缓存行需要变成无效状态
I 无效（Invalid）	此时该缓存行无效

假如说当前有一个cpu去主内存拿到一个变量x的值初始为1，放到自己的工作内存中。此时它的状态就是独享状态E，然后此时另外一个cpu也拿到了这个x的值，放到自己的工作内存中。此时之前那个cpu会不断地监听内存总线，发现这个x有多个cpu在获取，那么这个时候这两个cpu所获得的x的值的状态就都是共享状态S。然后第一个cpu将自己工作内存中x的值带入到自己的ALU计算单元去进行计算，返回来x的值变为2，接着会告诉给内存总线，将此时自己的x的状态置为修改状态M。而另一个cpu此时也会去不断的监听内存总线，发现这个x已经有别的cpu将其置为了修改状态，所以自己内部的x的状态会被置为无效状态I，等待第一个cpu将修改后的值刷回到主内存后，重新去获取新的值。这个谁先改变x的值可能是同一时刻进行修改的，此时cpu就会通过底层硬件在同一个指令周期内进行裁决，裁决是谁进行修改的，就置为修改状态，而另一个就置为无效状态，被丢弃或者是被覆盖（有争论）。

当然，MESI也会有失效的时候，缓存的最小单元是缓存行，如果当前的共享数据的长度超过一个缓存行的长度的时候，就会使MESI协议失败，此时的话就会触发总线加锁的机制，第一个线程cpu拿到这个x的时候，其他的线程都不允许去获取这个x的值。

2、不保证原子性

public class JMMTest02 {
    private static int num = 0;

    public static void add(){
        num++;
    }

    public static void main(String[] args) {

        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                for (int i1 = 0; i1 < 1000; i1++) {
                    add();
                }
            }).start();
        }

        while (Thread.activeCount()>2){
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + "" + num);
    }
}

num++并不是一个原子性操作，这样就会出现原子性问题

添加synchronized解决原子性问题

public class JMMTest02 {
    private  static  int num = 0;

    public synchronized static void add(){
        num++;
    }

    public static void main(String[] args) {

        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                for (int i1 = 0; i1 < 1000; i1++) {
                    add();
                }
            }).start();
        }

        while (Thread.activeCount()>2){
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + "" + num);
    }
}

然而，加了volatile也不会保证原子性

public class JMMTest02 {
    private volatile static int num = 0;

    public static void add(){
        num++;
    }

    public static void main(String[] args) {

        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                for (int i1 = 0; i1 < 1000; i1++) {
                    add();
                }
            }).start();
        }

        while (Thread.activeCount()>2){
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + "" + num);
    }
}

如何在不使用synchronized和lock的时候确保原子性呢，这时候我们要看一下原子类

public class JMMTest02 {
    private volatile static AtomicInteger num = new AtomicInteger();

    public synchronized static void add(){
        //num++;
        num.getAndIncrement();  //AtomicInteger + 1方法
    }

    public static void main(String[] args) {

        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                for (int i1 = 0; i1 < 1000; i1++) {
                    add();
                }
            }).start();
        }

        while (Thread.activeCount()>2){
            Thread.yield();
        }
        System.out.println(Thread.currentThread().getName() + "" + num);
    }
}

3、禁止指令重排

volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱序执行的现象，下面主要简单说明一下volatile是如何实现禁止指令重排优化的。先了解一个概念，内存屏障(Memory Barrier)。
内存屏障，又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执行 顺序，二是保证某些变量的内存可见性(利用该特性实现volatile的内存可见性)。由于编译 器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器 和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏 障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷出 各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。总之， volatile变量正是通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。

指令重排序是指编译器或CPU为了优化程序的执行性能而对指令进行重新排序的一种手段，重排序会带来可见性问题，所以在多线程开发中必须要关注并规避重排序。

从源代码到最终运行的指令，会经过如下两个阶段的重排序。

第一阶段，编译器重排序，就是在编译过程中，编译器根据上下文分析对指令进行重排序，目的是减少CPU和内存的交互，重排序之后尽可能保证CPU从寄存器或缓存行中读取数据。

第二阶段，处理器重排序，处理器重排序分为两个部分。

• 并行指令集重排序，这是处理器优化的一种，处理器可以改变指令的执行顺序。
• 内存系统重排序，这是处理器引入Store Buffer缓冲区延时写入产生的指令执行顺序不一致的问题。

volatile可以避免指令重排

• 上图中StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主 内存。
• 这里比较有意思的是，volatile写后面的StoreLoad屏障。此屏障的作用是避免 volatile写与 后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在 一个volatile写的后面是否需要插入一个StoreLoad屏障(比如，一个volatile写之后方 法立即return)。为了保证能正确 实现volatile的内存语义，JMM在采取了保守策略: 在每个volatile写的后面，或者在每个volatile读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑，JMM最终选择了在每个 volatile写的后面插入一个StoreLoad 屏障。因为volatile写-读内存语义的常见使用模式是:一个写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写 之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM在实现上的一个特点:首先确保正确性，然后再去追求执行效率。

上图中LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。
上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。

参考文章：

什么是指令重排

JMM模型

JAVA内存模型(JMM) && Volitale 详解