JMM、MESI、volatile篇

晓男是只银渐层
549 阅读18分钟

前言

在并发编程中有很多在开发中需要注意的协议和内存模型，常见的就是MESI缓存一致性协议和JMM内存模型。

MESI缓存一致性协议

缓存一致性协议发展背景：

现在的CPU基本都是多核CPU，服务器更是提供了多CPU的支持，而每个核心也都有自己独立的缓存，当多个核心同时操作多个线程对同一个数据进行更新时，如果核心2在核心1还未将更新的数据刷回内存之前读取了数据，并进行操作，就会造成程序的执行结果造成随机性的影响，这对于我们来说是无法容忍的。

而总线加锁是对整个内存进行加锁，在一个核心对一个数据进行修改的过程中，其他的核心也无法修改内存中的其他数据，这样对导致CPU处理性能严重下降。

缓存一致性协议提供了一种高效的内存数据管理方案，它只会对单个缓存行（缓存行是缓存中数据存储的基本单元）的数据进行加锁，不会影响到内存中其他数据的读写。

因此，我们引入了缓存一致性协议来对内存数据的读写进行管理。

MESI协议实际上是指四种状态：

状态描述监听任务
M 修改 (Modified)该Cache line有效，数据被修改了，和内存中的数据不一致，数据只存在于本Cache中。缓存行必须时刻监听所有试图读该缓存行相对就主存的操作，这种操作必须在缓存将该缓存行写回主存并将状态变成S（共享）状态之前被延迟执行。
E 独享、互斥 (Exclusive)该Cache line有效，数据和内存中的数据一致，数据只存在于本Cache中。缓存行也必须监听其它缓存读主存中该缓存行的操作，一旦有这种操作，该缓存行需要变成S（共享）状态。
S 共享 (Shared)该Cache line有效，数据和内存中的数据一致，数据存在于很多Cache中。缓存行也必须监听其它缓存使该缓存行无效或者独享该缓存行的请求，并将该缓存行变成无效（Invalid）。
I 无效 (Invalid)该Cache line无效。无

注意：

对于M和E状态而言总是精确的，他们在和该缓存行的真正状态是一致的，而S状态可能是非一致的。如果一个缓存将处于S状态的缓存行作废了，而另一个缓存实际上可能已经独享了该缓存行，但是该缓存却不会将该缓存行升迁为E状态，这是因为其它缓存不会广播他们作废掉该缓存行的通知，同样由于缓存并没有保存该缓存行的copy的数量，因此（即使有这种通知）也没有办法确定自己是否已经独享了该缓存行。

从上面的意义看来E状态是一种投机性的优化：如果一个CPU想修改一个处于S状态的缓存行，总线事务需要将所有该缓存行的copy变成invalid状态，而修改E状态的缓存不需要使用总线事务。

MESI状态转换

微信图片_20211021141412.png

1.触发事件

触发事件描述
本地读取（Local read）本地cache读取本地cache数据
本地写入（Local write）本地cache写入本地cache数据
远端读取（Remote read）其他cache读取本地cache数据
远端写入（Remote write）其他cache写入本地cache数据

2.cache分类：

前提：所有的cache共同缓存了主内存中的某一条数据。

本地cache:指当前cpu的cache。

触发cache:触发读写事件的cache。

其他cache:指既除了以上两种之外的cache。

注意：本地的事件触发 本地cache和触发cache为相同。

缓存行伪共享

CPU缓存系统中是以缓存行（cache line）为单位存储的。目前主流的CPU Cache 的 Cache Line 大小都是64Bytes。在多线程情况下，如果需要修改“共享同一个缓存行的变量”，就会无意中影响彼此的性能，这就是伪共享（False Sharing）。

举个例子: 现在有2个long 型变量 a 、b，如果有t1在访问a，t2在访问b，而a与b刚好在同一个cache line中，此时t1先修改a，将导致b被刷新！

怎么解决伪共享？

Java8中新增了一个注解：@Contended。加上这个注解的类会自动补齐缓存行，需要注意的是此注解默认是无效的，需要在jvm启动时设置 -XX:-RestrictContended 才会生效。


@Contended
public final static class  LgnTest {

public volatile long value = 0L;

// 老版本通过声明long行进行占位，达到占整个缓存行的效果
//public long p1, p2, p3, p4, p5, p6, p7;
}

JMM模型

如图所示： image.png JMM模型上是一个模型规范，规定了程序运行变量的访问规则。JVM在运行过程中的基本单位是线程，JVM会为每个线程创建自己的私有内存空间（可以理解成线程栈），而在java的内存模型中，所有的变量都会存在主存中，并且主存是一块共享的内存空间。每个线程访问主存的变量，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量。不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。

原子性

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。

在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行，因此对于这个问题不必太在意，知道这么回事即可。

原子性问题

除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过 synchronized和Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。

可见性

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

但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。

有序性

有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟现象。

数据同步八大原子操作

操作名称
lock(锁定)作用于主内存的变量，把一个变量标记为一条线程独占状态数据同步八大原子操作
unlock(解锁)作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
read(读取)作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
load(载入)作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
use(使用)作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
assign(赋值)作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量
store(存储)作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作
write(写入)作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

线程与主存交互如下图：

14410.png

指令重排

java语言规范规定JVM线程内部维持顺序化语义。即程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。

那么为什么需要指令重排呢？

JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。

14408.png

如下代码：

int x = 1;
int y = 2;
int z = x + y;

如上代码，在x = 1 和 y = 2 在编译器优化重排后，由于x 和 y 变量的赋值操作，无论谁先执行谁后执行，最终对z不产生影响，在一些情况下会存在指令重排，在指令重排之后可能就会先执行y的赋值再执行x的赋值操作。这样就是遵守了as-if-serial语义。

那么as-if-serial语义是什么呢？

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

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

happens-before 原则

happens-before原则并不是简单的代码编写的先后去执行，而是"A先于B去执行"，那么happens-before都有哪些原则呢？

1.程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作。

一段程序的执行，在单个线程中看起来是有序的。程序次序规则看起来是按顺序执行的，因为虚拟机可能会对程序指令进行重排序。虽然进行了重排序但是最终执行的结果是与程序顺序执行的结果是一致的。它只会对不存在数据依赖行的指令进行重排序。该规则是用来保证程序在单线程执行结果的正确性。但是无法保证程序在多线程执行结果的正确性。

2.锁定规则：一个unlock操作先行发生于后面对同一个锁的lock操作。即无论在单线程还是多线程中，同一个锁如果处于被锁定状态，那么必须先对锁进行释放操作，后面才能继续执行lock操作。

3.volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作。

4.传递规则：如果操作A先行发生于操作B，而操作B先行发生于操作C，则可以得出操作A先行发生于操作C

5.线程启动原则：Thread对象的start()方法先行发生于此线程的每一个动作

6.线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。

7.线程终结规则：线程中所以的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thhread.isAlive()的返回值手段检测到线程已经终止执行。

8.对象终结规则：一个对象的初始化完成先行于它的finalize()方法的开始。

volatile关键字

在java中有一些关键字是可以保证共享变量变化的可见性的像“volatile”关键字。 如上图当两个线程将主存的共享变量load到每个线程的私有内存空间，当其中一个线程对私有空间内部的变量副本写回到主存后那么对另一个线程是没有提醒的，而使用volatile关键字休息之后，另一个线程会立刻收到通知丢弃之前的变量副本重新从主存load新的共享变量。

volatile的可见性

请看如下代码：

// private static boolean flags = false;
private static volatile boolean flags = false;

public static void main(String[] args){
    Thread t1 = new Thread(()->{
        while (!flags){

        }
    },"t1");
    t1.start();

    try {
        Thread.sleep(500);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    Thread t2 = new Thread(()->{
        flags = true;
    },"t2");
    t2.start();
    }
}

当变量flags不使用volatile修饰的时候，线程2对flags的修改对于线程1来说是不可见的，在线程1中使用while关键字实际对于cpu的时间片轮转几乎是不释放，所以线程1一直会那到最开始的flags = true进行循环，而使用volatile关键字后，线程2对flags的修改会使线程1丢弃原来的flag重新去主从中获取flag的值。

我们可以查看在使用volatile和不适用volatile在字节码层面上的差别：

image.png

image.png

另外在使用volatile关键字，最终转换成汇编语言是会在变量上增加lock指令：

image.png

那么这个lock锁住的是什么呢？

其实现今的计算设计模型，volatile锁住是缓存行,老版本的机器锁住的总线。

我们怎么证明缓存行的存在呢？

public static void main(String[] args) {
    /* * 初始化数组 */
    arrays = new long[array_x][];
    for (int i = 0; i < array_x; i++) {
        arrays[i] = new long[array_y];
        for (int j = 0; j < array_y; j++) {
            arrays[i][j] = 1L;
        }
    }
    System.out.println("arrays初始化==========完毕");
    long sum = 0L;
    long start = System.currentTimeMillis();
    for (int r = 0; r < RUNS; r++) {
        for (int i = 0; i < array_x; i++) {
            for (int j = 0; j < array_y; j++) {
                sum += arrays[i][j];
            }
        }
    }

    System.out.println("以行的方式相加,消耗时间: " + (System.currentTimeMillis() - start));
    System.out.println("sumX:" + sum);
    sum = 0L;
    start = System.currentTimeMillis();
    for (int r = 0; r < RUNS; r++) {
        for (int j = 0; j < array_y; j++) {
            for (int i = 0; i < array_x; i++) {
                sum += arrays[i][j];
            }
        }
    }
    System.out.println("以列的方式相加,消耗时间: " + (System.currentTimeMillis() - start));
    System.out.println("sumY:" + sum);
}

image.png 可以看到同一个二维数组在不同的遍历方式上相加消耗的时间是有很大差距的，那么是什么愿意呢？

如图所示，缓存行可以相当于是二维数组的行，当第一种相加方式实际上一次性是获取了整个缓存行的数据，cpu将数据相加，第二次也是去整个缓存行，而第二种方式则是取每个缓存行的一个数据实际上循环次数为 1024 * 1024 * 16,而第一种方式相加最优的方式则是 1024 * 1024。

image.png

volatile禁止指令重排

volatile关键字另一个作用就是禁止指令重排优化，避免在多线程的情况下出现乱序执行最终导致同一个程序执行的结果不同。那么volatile是如何实现禁止指令重排的呢？

我们需要先了解一个概念，内存屏障(Memory Barrier）。

硬件层的内存屏障

Intel硬件提供了一系列的内存屏障，主要有： 

关键字屏障作用屏障类型
lfence是一种Load Barrier读屏障 
sfence是一种Store Barrier写屏障 
mfence是一种全能型的屏障有ifence和sfence的能力
Lock前缀Lock不是一种内存屏障Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG, CMPXCH8B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and XCHG等指令。

不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。 JVM中提供了四类内存屏障指令：

JVM中提供了四类内存屏障指令：

屏障类型指令示例说明
LoadLoadLoad1; LoadLoad; Load2保证load1的读取操作在load2及后续读取操作之前执行
StoreStoreStore1; StoreStore; Store2在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存
LoadStoreLoad1; LoadStore; Store2在stroe2及其后的写操作执行前，保证load1的读操作已读取结束
StoreLoadStore1; StoreLoad; Load2保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行

下面我们看一下最经典的double-check的单例模式：

public class DoubleCheck {
    // 使用volatile修饰，防止指令重排
    private volatile static DoubleCheck instance;
    private DoubleCheck() {
    }
    public static DoubleCheck getInstance() {
        //第一次检测
        if (instance == null) {
            // 同步
            synchronized (DoubleCheck.class) {
                // 第二次检查
                if (instance == null) {
                    
                    //多线程环境下可能会指令重排的问题
                    instance = new DoubleCheck();
                }
            }
        }
        return instance;
    }
}

在非多线程高并发的情况下其实是可以不加volatile关键字的，但是如果在高并发的场景下，编译器会对上面的代码进行编译优化。主要优化的点是instance = new DoubleCheck();虽然这是一行代码，但这一行的赋值操作并不是原子的，实际上可以分为一下步骤：

//1.分配对象内存空间 
memory = allocate();

//2.初始化对象
instance(memory);

//3.设置instance指向刚分配的内存地址，此时instance！=null
instance=memory;

以上是instance = new DoubleCheck();所需要的操作，当多线程的情况下，导致的指令重排那么就会出现下面的结构：

//1.分配对象内存空间 
memory = allocate();

//3.设置instance指向刚分配的内存地址，此时instance==null
instance=memory;

//2.初始化对象
instance(memory);

当双重检查锁执行到if判断可能会直接获取到未初始化但已分配内存地址的instace对象，这样接下来的逻辑使用instance的时候就会出现问题。而加volatile修饰之后就会禁止指令重排解决上面的问题。

avatar
文章
阅读
粉丝