浅分析Java volatile关键字-CSDN博客

浅分析Java volatile关键字

大家好，前不久看了掘金一篇帖子原贴请点链接，那么今天就来给大家分享一下从这篇帖子中学到的volatile以及线程安全相关的知识点。

Java内存模型

在介绍volatile关键字之前，还是先给大家讲讲Java的内存模型

Java内存模型

Java的内存模型规定所有的变量都存储在主内存中，每条线程中还有属于自己的工作内存，现成的工作内存中保存了被该线程所使用到的变量(这些变量是从主内存中拷贝过来的)，线程对变量的所有操作都必须在工作内存中进行，不同线程之间也无法访问到对方的工作内存中的变量，线程间变量值的传递都需要通过主内存来完成(从主内存读取共享变量到工作内存->在工作内存进行修改->写回主内存供其他线程访问)

并发编程的三大概念

1. 可见性

可见性是一种较为复杂的属性，通常我们的直觉在这一部分很大程度来说都是错的，并且通常我们没有办法保证执行将共享变量读取到工作内存的线程读取的一定是最新的共享变量值，也就是说我们不能保证一个线程在执行读操作的时候能适时看到其他线程刚刚写入的值或者说已经写入的值，有的时候我们的确无法控制，为了确保多个线程之间对共享变量的可见性，我们必须使用一些同步的策略。

可见性是指线程之间的可见性，具体的就是一个线程修改的结果对其他线程是可见的，如何实现这个可见性?上面说到了线程之间变量的传递需要通过主内存来完成，那么可见性可以理解为一个线程读取共享变量到自己的工作线程后，执行完自己对该共享变量的操作后，立即将其写回主内存，这样也就保证了对其他线程的可见性。

比如，使用volatile关键字，就能保证线程之间具有可见性，volatile关键字修饰的变量不允许线程内部缓存和重排序，即直接修改内存。 但是volatile只能让它修饰的内容具有可见性，但是不能保证它的原子性。比如

volatile int a = 0;
//在线程中对a变量执行自增操作
……
new Thread(() -> {
            a++;
        }).start();
……

虽然volatile修饰了a变量，但是这也只是保证了a变量具有可见性，但是不能保证a++;这一步自增操作具有原子性。a++;是一个非原子操作，也就是说这个操作仍然可能是一个线程不安全的操作。

而对于普通的没有volatile,synchronized等修饰的共享变量，这个时候就更不能保证它的可见性了，因为普通共享变量被线程修改之后，并不知道什么时候会被写回主内存，也就是说如果在这个时候遇到别的线程需要访问这个共享变量，访问的极有可能是一个无效的值进而造成线程的不安全。

同时在Java中通过synchronized,Lock两个关键字也可保证可见性，但是这两种方法保证可见性的原理与volatile并不相同，synchronized,Lock两个关键字能保证在同一时刻只有一条线程能够获取共享变量的锁，并且对该共享变量进行操作，并且在释放锁之前会对共享变量进行写回操作，所以也就相当于顺序执行对共享变量的操作，这样实现的共享变量的可见性，与volatile是不一样的

2. 原子性

即一个操作或者多个操作要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。在Java中，对基本数据类型的变量的读取和赋值操作是原子性操作，即这些操作是不可被中断的，要么执行，要么不执行。

比如a=0; (a是非long和非double类型) 这一步赋值操作，这就是一个不可分割的操作，所以我们称这种赋值操作为原子操作，刚刚提到了a++;不具有原子性，是因为a++;这个操作实际上等同于a = a + 1;这一步操作是可分割的，也就是说执行a++这个操作的时候可以分割为读取a再对a进行+1操作，这个时候就需要我们使用synchronized关键字保证这个操作是原子操作。

那么为什么又说a=0;这个操作的变量a除了long和double之外就是一个原子操作呢？分享一篇CSDN博客中的一句话

“深入java虚拟机”中提到，int等不大于32位的基本类型的操作都是原子操作，但是某些jvm对long和double类型的操作并不是原子操作，这样就会造成错误数据的出现。

以及一篇以虚构小k面试为故事的Java原子操作与并发，介绍的内容生动又不失技术内容，最终告诉我们long型和double型的变量赋值可能存在并发执行和赋值操作这两个大坑。

这篇文章中最后总结到：Java 基础类型中，long 和 double 是 64 位长的。32 位架构 CPU 的算术逻辑单元（ALU）宽度是 32 位的，在处理大于 32 位操作时需要处理两次。当然也取决于不同的操作系统，这个问题因为我也没有深入地了解过操作系统和JVM所以大家有感兴趣的话自行下去搜索吧。
同时为了解决这种赋值的并发问题Java提供了一些并发处理包java.util.concurrent.atomic
其中就有AtomicBoolean、AtomicInteger、AtomicLong三大类。
我们进入AtomicLong的源码看看

private volatile long value;

/**
 * Creates a new AtomicLong with the given initial value.
 *
 * @param initialValue the initial value
 */
public AtomicLong(long initialValue) {
    value = initialValue;
}

可以看到构造AtomicLong对象的时候会将构造器传入的long型初始化值赋值给已经声明为volatile的成员变量，这样也就保证了该long型的变量的原子性

3. 有序性

有序性就是程序执行的顺序按照代码的先后顺序执行。

因为这里的东西涉及到的地方自己没有了解过所以就引用原贴作者的话给大家分享：

什么是指令重排序，一般来说，处理器为了提高程序运行效率，可能会对输入代码进行优化，它不保证程序中各个语句的执行先后顺序同代码中的顺序一致，但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。指令重排序不会影响单个线程的执行，但是会影响到线程并发执行的正确性。也就是说，要想并发程序正确地执行，必须要保证原子性、可见性以及有序性。只要有一个没有被保证，就有可能会导致程序运行不正确。在Java内存模型中，允许编译器和处理器对指令进行重排序，但是重排序过程不会影响到单线程程序的执行，却会影响到多线程并发执行的正确性。在Java里面，可以通过volatile关键字来保证一定的“有序性”。另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

volatile原理

Java提供了一种相对于synchronized,Lock相对较弱的同步机制，volatile修饰的变量可以保证该变量在并发时的可见性，因为一旦一个变量被声明为了volatile，编译器和运行时都会注意这个变量是共享变量，因此不会将该变量上的操作与其它内存操作一起进行指令重排，volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，因此在别的线程读取上一个线程操作过后的共享变量时，总是能读取到最新的共享变量，因为其保证了共享变量的可见性。

相对于synchronized,Lock的较弱同步机制主要体现在，线程对其修饰的共享变量进行操作的时候并不会进行加锁操作，这也就相当于是一种弱同步机制。

当对非 volatile变量进行读写的时候，每个线程先从内存拷贝变量到CPU缓存中。如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同的 CPU cache 中。而声明变量是 volatile 的，JVM 保证了每次读变量都从内存中读，跳过 CPU cache 这一步。

1. volatile的可见性

如果存在一个共享变量被volatile修饰，那就有了两层意思：

1. 保证不同线程对该共享变量操作时的可见性，即一个线程对共享变量修改之后会立即被写回内存以保证它的可见性。

2.禁止对共享变量进行操作的语句进行指令重排序。

举一个原贴的例子说明

//线程1boolean stop = false;while(!stop){    doSomething();}//线程2stop = true;

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

下面解释一下这段代码为何有可能导致无法中断线程。在前面已经解释过，每个线程在运行过程中都有自己的工作内存，那么线程1在运行的时候，会将stop变量的值拷贝一份放在自己的工作内存当中。

那么当线程2更改了stop变量的值之后，但是还没来得及写入主存当中，线程2转去做其他事情了，那么线程1由于不知道线程2对stop变量的更改，因此还会一直循环下去。

但是用volatile修饰之后就变得不一样了：

第一：使用volatile关键字会强制将修改的值立即写入主存；

第二：使用volatile关键字的话，当线程2进行修改时，会导致线程1的工作内存中缓存变量stop的缓存行无效（反映到硬件层的话，就是CPU的L1或者L2缓存中对应的缓存行无效）；

第三：由于线程1的工作内存中缓存变量stop的缓存行无效，所以线程1再次读取变量stop的值时会去主存读取。 那么在线程2修改stop值时（当然这里包括2个操作，修改线程2工作内存中的值，然后将修改后的值写入内存），会使得线程1的工作内存中缓存变量stop的缓存行无效，然后线程1读取时，发现自己的缓存行无效，它会等待缓存行对应的主存地址被更新之后，然后去对应的主存读取最新的值。那么线程1读取到的就是最新的正确的值。

这也正是利用了volatile的可见性

2. 原子性

public class ThreadTest {
    public volatile int number = 0;

    public void increase() {
        number++;
    }

    public static void main(String[] args) {
        final ThreadTest test = new ThreadTest();
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                for (int j = 0; j < 1000; j++) test.increase();
            }).start();
        }
        //此方法返回活动线程的当前线程的线程组中的数量
        //当活跃线程数>2时
        //main线程yield等待等待上面十个线程执行完毕
        while (Thread.activeCount() > 2) Thread.yield();

        System.out.println(test.number);
    }
}

再问大家一个问题，上面的代码输出结果是多少？

使用了volatile声明了一个int类型的number变量初值为0，声明一个方法对number自增，在mian方法中开启十个线程对test对象执行它的increase方法，Thread.activeCount()方法查看当前线程的活跃线程数量，当除了主线程还有线程处于活跃状态时，说明上面的10个线程没有执行完它对test对象进行的increase方法，那么结果为10000吗？

我们来测试一下

9401    Process finished with exit code 0
9851    Process finished with exit code 0
8901    Process finished with exit code 0
9727    Process finished with exit code 0
9181    Process finished with exit code 0
…………

跑了五遍，没有一次是10000结果，有人就会问了，这是为什么，最终的结果都比10000要小？而且共享变量加了volatile修饰符，这又是为什么？

还记得上面说的自增操作是没有原子性是可以拆分的吗？ 问题就是出在这里，increase方法中执行的对共享变量的操作就是自增操作，没有保证共享变量操作的原子性，所以会出现线程不安全的情况。我们来仔细分析一下这种情况：

这里面就有一个误区了，volatile关键字能保证可见性没有错，但是上面的程序错在没能保证原子性。可见性只能保证每次读取的是最新的值，但是volatile没办法保证对变量的操作的原子性。

假如：某个时刻number的值为10，线程1对number进行自增操作，首先读取了number的值到工作内存，然后线程1被阻塞，这时线程2开始读取number的值，因为线程1此时被阻塞没有执行完自增操作，更没有写回主存，所以这时线程2读取到的还是一开始的10，当线程2执行完了操作之后写回主存11，这时线程1接着进行自增的+1操作，但是等到线程1执行完所有的对number共享变量的操作之后立即写回主存时写回的值还是11，所以两个线程对number进行自增操作相当于只是进行了一次，volatile修饰符无法保证对变量的操作是原子性的！这时可能就更需要synchronized或Lock上锁保证线程的安全，来保证操作的原子性，也可通过封装好的AtomicInteger来实现。

3. volatile保证有序性

这里对有序性的介绍就引用原文了，也为了更好让大家理解

在前面提到volatile关键字能禁止指令重排序，所以volatile能在一定程度上保证有序性。

volatile关键字禁止指令重排序有两层意思：

1）当程序执行到volatile变量的读操作或者写操作时，在其前面的操作的更改肯定全部已经进行，且结果已经对后面的操作可见；在其后面的操作肯定还没有进行；

2）在进行指令优化时，不能将在对volatile变量的读操作或者写操作的语句放在其后面执行，也不能把volatile变量后面的语句放到其前面执行。

volatile的实现原理

同样引用原文内容

处理器为了提高处理速度，不直接和内存进行通讯，而是将系统内部的数据读到内部缓存后在进行操作，但操作完之后不知道什么时候会写入内存。

如果对声明了volatile变量进行写操作时，JVM会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写会到系统内存。这一步确保了如果有其他线程对声明了volatile变量进行修改，则立即更新主内存中数据。

但这时候其他处理器的缓存还是旧的，所以在多处理器环境下，为了保证各个处理器缓存一致，每个处理会通过嗅探在总线上传播的数据来检查自己的缓存是否过期，当处理器发现自己缓存行对应的内存地址被修改了，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作时，会强制重新从系统内存把数据读到处理器缓存里。这一步确保了其他线程获得的声明了volatile变量都是从主内存中获取最新的。

Lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成。