JUC——volatile关键字的使用以及底层原理浅析

最新推荐文章于 2024-02-20 12:05:05 发布

cj_eryue

最新推荐文章于 2024-02-20 12:05:05 发布

阅读量233

点赞数 2

分类专栏： java基础文章标签：多线程 java

本文链接：https://blog.csdn.net/cj_eryue/article/details/111179898

版权

java基础专栏收录该内容

18 篇文章 0 订阅

订阅专栏

volatile在平常开发中可能使用的场景有限，但是在JUC包下却是被大量使用：

volatile和CAS是AQS的基石，AQS是JUC的基石。

我们先来先看一个列子：

package com.cjian.JUC;

/**
 * @description:
 * @author: CJ
 * @time: 2020/12/9 14:02
 */
public class VolatileDemo {

    public static void main(String[] args) {
        ThreadDemo threadDemo = new ThreadDemo();
        new Thread(threadDemo).start();

        while(true){
            if(threadDemo.isFlag()){
                System.out.println("---------------");
                break;
            }
        }
    }

}

class ThreadDemo implements Runnable{

    private boolean flag = false;
    @Override
    public void run() {

        try {
            Thread.sleep(2000);
            setFlag(true);
            System.out.println("2s后---->"+flag);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public boolean isFlag() {
        return flag;
    }

    public void setFlag(boolean flag) {
        this.flag = flag;
    }
}

运行结果：

并没有如同我们预想的那样，会输出---------。这里如果我们给flag 加上volatile，就可以解决问题，这是一个典型的volatile的使用场景：状态标记量，另一个典型的使用场景为单例模式

在了解为什么要使用volatile关键字之前，我们需要先了解以下2点，也正是volatile关键字所解决的问题：

什么是指令重排？
什么是内存/缓存一致性问题？

指令重排:

如下代码：

上面代码定义了一个 int 型变量，定义了一个 boolean 类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句 1 是在语句 2 前面的，那么 JVM 在真正执行这段代码的时候会保证语句 1 一定会在语句 2 前面执行吗？不一定，为什么呢？这里可能会发生指令重排序（Instruction Reorder）

下面解释一下什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。

比如上面的代码中，语句 1 和语句 2 谁先执行对最终的程序结果并没有影响，那么就有可能在执行过程中，语句 2 先执行而语句 1 后执行。

上述代码中，正常执行的顺序是语句1-->语句2-->语句3-->语句4。有没有可能语句3与语句4的执行顺序发生重排序，即执行顺序变成语句1-->语句2-->语句4-->语句3？

不可能，因为如果语句3与语句4的执行顺序发生变化，那么r的值是不同的。而重排序必须要保证重排序后，执行的结果与未重排序是一样的

在单线程的环境下，指令重排序是没有问题的，但是在并发的情况下，指令重排序，那么执行运行的结果可能不是我们期望的，如下代码（inited初始值为false）

上述代码中，语句1与语句2由于不存在数据依赖，所以存在代码重排序的可能，如果发生重排序，先执行语句2，这时候线程2中的while(!inited)条件不能满足，则直接执行doSomethingwithconifg(context)；由于context没有初始化，这个时候调用context会抛出异常

从上面可以看出，指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。

缓存一致性问题

内存模型相关概念

大家都知道，计算机在执行程序时，每条指令都是在 CPU 中执行的，而执行指令过程中，势必涉及到数据的读取和写入。由于程序运行过程中的临时数据是存放在主存（物理内存）当中的，这时就存在一个问题，由于CPU执行速度很快，而从内存读取数据和向内存写入数据的过程跟 CPU 执行指令的速度比起来要慢的多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在 CPU 里面就有了高速缓存（这也导致了多核时代的内存一致性问题）。

也就是，当程序在运行过程中，会将运算需要的数据从主存复制一份到 CPU 的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。举个简单的例子，比如这段代码：

a = a + 1；

当线程执行这个语句时，会先从主存当中读取a的值，然后复制一份到高速缓存当中，然后 CPU 执行指令对 a 进行加 1 操作，然后将数据写入高速缓存，最后将高速缓存中a最新的值刷新到主存当中。

这个代码在单线程中运行是没有任何问题的，但是在多线程中运行就会有问题了。在多核 CPU 中，每条线程可能运行于不同的 CPU 中，因此每个线程运行时有自己的高速缓存（对单核CPU来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的）。

假如同时有 2 个线程执行这段代码，假如初始时 a 的值为 0，那么我们希望两个线程执行完之后 a 的值变为 2。但是事实会是这样吗？

可能存在下面一种情况：初始时，两个线程分别读取a的值存入各自所在的 CPU 的高速缓存当中，然后线程 1 进行加 1 操作，然后把a的最新值 1 写入到内存。此时线程 2 的高速缓存当中 a 的值还是 0，进行加 1 操作之后，a 的值为1，然后线程 2 把 a 的值写入内存。

最终结果 a 的值是 1，而不是 2。这就是著名的缓存一致性问题。通常称这种被多个线程访问的变量为共享变量。也就是说，如果一个变量在多个CPU中都存在缓存（一般在多线程编程时才会出现），那么就可能存在缓存不一致的问题。

为了解决缓存不一致性问题，通常来说有以下 2 种解决方法：

通过在总线加 LOCK# 锁的方式
通过缓存一致性协议

这 2 种方式都是硬件层面上提供的方式。

在早期的 CPU 中，是通过在总线上加 LOCK# 锁的形式来解决缓存不一致的问题。因为 CPU 和其他部件进行通信都是通过总线来进行的，如果对总线加 LOCK# 锁的话，也就是说阻塞了其他 CPU 对其他部件访问（如内存），从而使得只能有一个 CPU 能使用这个变量的内存。比如上面例子中如果一个线程在执行 a = a +1，如果在执行这段代码的过程中，在总线上发出了 LCOK# 锁的信号，那么只有等待这段代码完全执行完毕之后，其他CPU 才能从变量 i 所在的内存读取变量，然后进行相应的操作。这样就解决了缓存不一致的问题。

但是上面的方式会有一个问题，由于在锁住总线期间，其他 CPU 无法访问内存，导致效率低下。

所以就出现了缓存一致性协议。最出名的就是 Intel 的 MESI 协议，MESI 协议保证了每个缓存中使用的共享变量的副本是一致的。它核心的思想是：当 CPU 写数据时，如果发现操作的变量是共享变量，即在其他 CPU 中也存在该变量的副本，会发出信号通知其他 CPU 将该变量的缓存行置为无效状态，因此当其他 CPU 需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

由上述我们知道，代码在执行的过程中，指令重排序和缓存一致性问题都是我们需要解决的，而volatile关键字就可以解决这两个问题。

Volatile是如何解决的？

在介绍volatile语义实现原理之前，我们先来看两个与CPU相关的专业术语：

内存屏障（memory barriers）：一组处理器指令，用于实现对内存操作的顺序限制。

缓存行（cache line）：CPU高速缓存中可以分配的最小存储单位。处理器填写缓存行时会加载整个缓存行。

内存屏障分为两种

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的写入对所有处理器可见。它的开销是四种屏障中最大的。在大多数处理器的实现中，这个屏障是个万能屏障，兼具其它三种内存屏障的功能。

额外的提一下 happens-before 原则

happens-before原则（先行发生原则）：

程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作
volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作
传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作
线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始

这8条原则摘自《深入理解Java虚拟机》。

这8条规则中，前4条规则是比较重要的，后4条规则都是显而易见的。

下面我们来解释一下前4条规则：

对于程序次序规则来说，我的理解就是一段程序代码的执行在单个线程中看起来是有序的。注意，虽然这条规则中提到“书写在前面的操作先行发生于书写在后面的操作”，这个应该是程序看起来执行的顺序是按照代码顺序执行的，因为虚拟机可能会对程序代码进行指令重排序。虽然进行重排序，但是最终执行的结果是与程序顺序执行的结果一致的，它只会对不存在数据依赖性的指令进行重排序。因此，在单个线程中，程序执行看起来是有序执行的，这一点要注意理解。事实上，这个规则是用来保证程序在单线程中执行结果的正确性，但无法保证程序在多线程中执行的正确性。

第二条规则也比较容易理解，也就是说无论在单线程中还是多线程中，同一个锁如果出于被锁定的状态，那么必须先对锁进行了释放操作，后面才能继续进行lock操作。

第三条规则是一条比较重要的规则，也是后文将要重点讲述的内容。直观地解释就是，如果一个线程先去写一个变量，然后一个线程去进行读取，那么写入操作肯定会先行发生于读操作。

第四条规则实际上就是体现happens-before原则具备传递性。

主内存和本地内存间的交互

主内存和本地内存的交互即一个变量是如何从主内存中拷贝到本地内存又是如何从本地内存中回写到主内存中的实现，Java内存模型提供了8中操作来完成主内存和本地内存之间的交互。它们分别如下：

lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才能被其它线程锁定。
read（读取）：作用于主内存的变量，它把一个变量从主内存传输到线程的本地内存中，以便随后的load动作使用。
load（载入）：作用于本地内存的变量，它把read操作从主内存中的到的变量值放入本地内存的变量副本中。
use（使用）：作用于本地内存的变量，它把本地内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量值的字节码指令时将会执行这个操作。
assign（赋值）：作用于本地内存的变量，它把一个从执行引擎接收到的变量赋予给本地内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时将会执行这个操作。
store（存储）：作用于本地内存的变量，它把本地内存中的变量的值传递给主内存中，以便后面的write操作使用。
write（写入）：作用于主内存的变量，它把store操作从本地内存中得到的变量的值放入主内存的变量中。

从上面8种操作中，我们可以看出，当一个变量从主内存复制到线程的本地内存中时，需要顺序的执行read和load操作，当一个变量从本地内存同步到主内存中时，需要顺序的执行store和write操作。Java内存模型只要求上述的2组操作是顺序的执行的，但并不要求连续执行。比如对主内存中的变量a 和 b 进行访问时，有可能出现的顺序是read a read b load b load a。除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足以下规则：

不允许read和load，store和write操作单独出现，这2组操作必须是成对的。
不允许一个线程丢弃它最近的assign操作。即变量在线程的本地内存中改变后必须同步到主内存中。
不允许一个线程无原因的把数据从线程的本地内存同步到主内存中。
不允许线程的本地内存中使用一个未被初始化的变量。
一个变量在同一时刻只允许一个线程对其进行lock操作，但是一个线程可以对一个变量进行多次的lock操作，当线程对同一变量进行了多次lock操作后需要进行同样次数的unlock操作才能将变量释放。
如果一个变量执行了lock操作，则会清空本地内存中变量的拷贝，当需要使用这个变量时需要重新执行read和load操作。
如果一个变量没有执行lock操作，那么就不能对这个变量执行unlock操作，同样也不允许unlock一个被其它线程执行了lock操作的变量。也就是说lock 和unlock操作是成对出现的并且是在同一个线程中。
对一个变量执行unlock操作之前，必须将这个变量的值同步到主内存中去。