第六章volatile详解-Toy模板网

这篇具有很好参考价值的文章主要介绍了第六章volatile详解。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

volatile修饰的变量有2大特点

可以保证

可见性
有序性

为什么能实现这些功能，其底层原理就是内存屏障

volatile的内存语义

volatile关键字可以保证共享变量可见性，相较于普通的共享变量，使用volatile关键字可以保证共享变量的可见性

当线程读取的是volatile关键字时，JMM会把该线程对应的工作内存设置为无效,线程直接从主内存中读取该值到工作内存中
- yield和sleep会导致线程让出CPU，当线程再次调度回CPU，有可能会重新读主存（JVM规范明确表示，yield和sleep方法不一定会强行刷新工作内存，读取主存，但是volatile会强行刷新内存）
当线程写的是volatile关键字变量，将当前修改后的变量值（工作内存中）立即刷新到主内存，且其他正在读此变量的线程会等待（不是阻塞），直到写回主内存操作完成，保证读的一定是刷新后的主内存值

一句话，volatile修饰的变量在某个工作内存修改后立刻会刷新会主内存，并把其他工作内存的该变量设置为无效。

内存屏障

回忆volatile的作用

可见性
- 立即刷新回主内存+失效处理。
有序性
- 禁止指令重排：存在数据依赖关系的禁止重排。

是什么

内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。
内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性，但volatile无法保证原子性。
- 内存屏障之前的所有写操作都要回写到主内存，
- 内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
- 一句话：对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读，也叫写后读。

内存屏障分类

上一章讲解过happens-before先行发生原则，类似接口规范，落地？
落地靠什么？你凭什么可以保证？你管用吗？

粗分两种

写屏障(Store Memory Barrier) ：告诉处理器在写屏障之前将所有存储在缓存(store bufferes) 中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。

读屏障(Load Memory Barrier) ：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。

细分四种

第六章volatile详解

什么叫保证有序性

禁止指令重排
- 通过内存屏障禁止重排

重排序有可能影响程序的执行和实现，因此，我们有时候希望告诉JVM你别“自作聪明”给我重排序，我这里不需要排序，听主人的。
对于编译器的重排序， JMM会根据重排序的规则，禁止特定类型的编译器重排序。
对于处理器的重排序， Java编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序。

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后

对 volatile 变量的读指令前会加入读屏障
读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

写屏障(Store Memory Barrier) ：告诉处理器在写屏障之前将所有存储在缓存(store bufferes) 中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。

读屏障(Load Memory Barrier) ：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。

happens-before之volatile变量规则

对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读，也叫写后读。

第六章volatile详解

这里暂时先有个印象着就行

当第一个操作为volatile读时，不论第二个操作是什么，都不能重排序。这个操作保证了volatile读之后的操作不会被重排到volatile读之前。
当第二个操作为volatile写时，不论第一个操作是什么，都不能重排序。这个操作保证了volatile写之前的操作不会被重排到volatile写之后。
当第一个操作为volatile写时，第二个操作为volatile读时，不能重排。

JMM就将内存屏障插入策略分为4种规则

读屏障

在每个volatile读操作的后面插入一个LoadLoad屏障
在每个volatile读操作的后面插入一个LoadStore屏障

写屏障

在每个volatile写操作的前面插入一个StoreStore屏障
在每个volatile写操作的后面插入一个StoreLoad屏障

第六章volatile详解

volatile特性

如何保证可见性

volatile 的底层实现原理是内存屏障，Memory Barrier（Memory Fence）

对 volatile 变量的写指令后会加入写屏障
保证在该屏障之前的，对共享变量的改动，都同步到主存当中

对 volatile 变量的读指令前会加入读屏障
保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

写屏障(Store Memory Barrier) ：告诉处理器在写屏障之前将所有存储在缓存(store bufferes) 中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。

读屏障(Load Memory Barrier) ：处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。

说明

保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见。

例子

public class VolatileTest1 {
//    static boolean flag = true;//不加volatile，没有可见性
    static volatile boolean flag = true;//加volatile，有可见性
    public static void main(String[] args) throws InterruptedException {
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"\t come in");
            while (flag){//默认flag是true,如果未被修改就一直循环，下面那句话也打不出来

            }
            System.out.println(Thread.currentThread().getName()+"\t flag被修改为false,退出.....");

        },"t1").start();
        //暂停几秒
        TimeUnit.SECONDS.sleep(2);
        flag=false;
        System.out.println("main线程修改完成");
    }
}
//没有volatile时
//t1   come in
//main线程修改完成
//--------程序一直在跑（在循环里）

//有volatile时
//t1   come in
//main线程修改完成
//t1   flag被修改为false,退出.....

上述代码原理解释

线程t1中为何看不到被主线程main修改为false的flag的值？

问题可能:

主线程修改了flag之后没有将其刷新到主内存，所以t1线程看不到。
主线程将flag刷新到了主内存，但是t1一直读取的是自己工作内存中flag的值，没有去主内存中更新获取flag最新的值。

我们的诉求：

线程中修改了工作内存中的副本之后，立即将其刷新到主内存；
工作内存中每次读取共享变量时，都去主内存中重新读取，然后拷贝到工作内存。

解决：

使用volatile修饰共享变量，就可以达到上面的效果，被volatile修改的变量有以下特点：
- 线程中读取的时候，每次读取都会去主内存中读取共享变量最新的值，然后将其复制到工作内存
- 线程中修改了工作内存中变量的副本，修改之后会立即刷新到主内存

volatile变量的读写过程

Java内存模型定义了8种每个线程工作内存与物理主内存之间的原子操作

read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→lock(锁定)→unlock(解锁)

read: 作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存
load: 作用于工作内存，将read从主内存传输的变量值放入工作内存变量副本中，即数据加载
use: 作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作
assign: 作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作
store: 作用于工作内存，将赋值完毕的工作变量的值写回给主内存
write: 作用于主内存，将store传输过来的变量值赋值给主内存中的变量

由于上述6条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁，所以，JVM提供了另外两个原子指令：

lock: 作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程。
unlock: 作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用

其中最核心的操作是在于我们的write操作，当我们从工作内存写到主内存的时候，会进行lock加锁操作，加锁后会清空其他线程工作内存变量的值，如果其他线程要使用该变量前必须重写从主内存加载值，当write完毕后，进行unlock进行解锁，这样就保证了可见性

这里的锁只是锁了些变量的过程，也就是只有写完之后，其他线程才能到主内存去读数据

为何没有原子性

volatile变量的复合操作不具有原子性，比如number++

例子

synchronized和volatile代码演示

class MyNumber{
    //volatile int num=0;
    int num=0;
    public synchronized void add(){
        num++;
    }
}
public class VolatileNoAtomicDemo {
    public static void main(String[] args) {
        MyNumber myNumber = new MyNumber();
        for (int i = 0; i <10; i++) {
            new Thread(()->{
                for (int j = 0; j < 100; j++) {
                    myNumber.add();
                }
            }).start();
        }
        //暂停几秒钟线程
        try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { e.printStackTrace(); }
        System.out.println(Thread.currentThread().getName() + "\t" + myNumber.num);

    }

}
//-------------volatile情况下
//main  941
//-----------synchronized请款下
//main  1000

读取赋值一个普通变量的情况

当线程1对主内存对象发起read操作到write操作第一套流程的时间里，线程2随时都有可能对这个主内存对象发起第二套操作

当线程1开始了volatile的读写流程的时候，线程2可以在其任何时候的流程的时候进行发起read操作，因为我们的volatile的锁只是锁了在wirte的写流程

不保证原子性

从底层来说，i++或者number++（在执行引擎操作时）其实是分了三步的：数据加载 、数据计算 、数据赋值 。而这三步非原子操作

第六章volatile详解

对于volatile变量具备可见性，JVM只是保证从主内存加载到线程工作内存的值是最新的，也仅是数据加载时是最新的。
但是多线程环境下，“数据计算”和“数据赋值”操作可能多次出现，若数据在加载之后，若主内存volatile修饰变量发生修改之后，线程工作内存中的操作将会作废去读主内存最新值，操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步，进而导致数据不一致。由此可见volatile解决的是变量读取时的可见性问题，但无法保证原子性，对于多线程修改主内存共享变量的场景必须使用加锁同步。
就比如这个i++操作，当你从主内存加载了5进入，并且加载进了工作内存，正当要进行++操作的时候，线程2进行了读取操作，也是从主内存读取了5，因为线程1没有进行write操作，所有主内存还是最新的值，符合volatile的特性，然后线程进行了8个一套操作，然后变成6写入主内存，线程1的5就失效了，就需要进行重新从内存读取到6，但是这次++操作是丢失了，所有还是线程不安全的

结论

volatile不适合参与到依赖当前值的运算，如i=i+1，i++之类的
那么依靠可见性的特点volatile可以用在哪些地方呢？通常volatile用作保存某个状态的boolean值或or int值。 （一旦布尔值被改变迅速被看到，就可以做其他操作）

禁止指令重排

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序
不存在数据依赖关系，可以重排序；
存在数据依赖关系，禁止重排序
- 数据依赖性：若两个操作访问同一变量，且这两个操作中有一个为写操作，此时两操作间就存在数据依赖性。

但重排后的指令绝对不能改变原有的串行语义！这点在并发设计中必须要重点考虑！

数据依赖的实例

第六章volatile详解

不存在数据依赖关系，可以重排序 ===> 重排序OK 。

存在数据依赖关系，禁止重排序===> 重排序发生，会导致程序运行结果不同。
编译器和处理器在重排序时，会遵守数据依赖性，不会改变存在依赖关系的两个操作的执行,但不同处理器和不同线程之间的数据性不会被编译器和处理器考虑，其只会作用于单处理器和单线程环境

如何正确使用volatile（实际工作）

单一赋值可以，但是含有符合运算赋值不可以（比如i++）

下面这两个单一赋值可以的
- volatile int a = 10;
- volatile boolean flag = false

状态标志，判断业务是否结束

//这个前面讲过
public class UseVolatileDemo{
    private volatile static boolean flag = true;

    public static void main(String[] args){
        new Thread(() -> {
            while(flag) {
                //do something......循环
            }
        },"t1").start();

        //暂停几秒钟线程
        try { TimeUnit.SECONDS.sleep(2L); } catch (InterruptedException e) { e.printStackTrace(); }

        new Thread(() -> {
            flag = false;
        },"t2").start();
    }
}

开销较低的读，写锁策略

当读远多于写

最土的方法就是加两个synchronized，但是读用volatile，写用synchronized可以提高性能

public class UseVolatileDemo{
    //
   // 使用：当读远多于写，结合使用内部锁和 volatile 变量来减少同步的开销
   // 理由：利用volatile保证读取操作的可见性；利用synchronized保证复合操作的原子性
     
    public class Counter {
        private volatile int value;

        public int getValue(){
            return value;   //利用volatile保证读取操作的可见性
         }
        public synchronized int increment(){
            return value++; //利用synchronized保证复合操作的原子性
        }
    }
}

单例模式双重锁案例

public class SafeDoubleCheckSingleton
{
    private static SafeDoubleCheckSingleton singleton; //-----这里没加volatile
    //私有化构造方法
    private SafeDoubleCheckSingleton(){
    }
    //双重锁设计
    public static SafeDoubleCheckSingleton getInstance(){
        if (singleton == null){
            //1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象
            synchronized (SafeDoubleCheckSingleton.class){
                if (singleton == null){
                    //隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程读取
                    singleton = new SafeDoubleCheckSingleton();
                    //实例化分为三步
                    //1.分配对象的内存空间
                    //2.初始化对象
                    //3.设置对象指向分配的内存地址
                }
            }
        }
        //2.对象创建完毕，执行getInstance()将不需要获取锁，直接返回创建对象
        return singleton;
    }
}

单线程情况下

单线程环境下(或者说正常情况下)，在"问题代码处"，会执行如下操作，保证能获取到已完成初始化的实例

//三步
memory = allocate(); //1.分配对象的内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置对象指向分配的内存地址

多线程情况下（由于指令重排序）
隐患：多线程环境下，在"问题代码处"，会执行如下操作，由于重排序导致2,3乱序，后果就是其他线程得到的是null而不是完成初始化的对象。（没初始化完的就是null）

正常情况

//三步
memory = allocate(); //1.分配对象的内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置对象指向分配的内存地址

非正常情况

//三步
memory = allocate(); //1.分配对象的内存空间
instance = memory; //3.设置对象指向分配的内存地址---这里指令重排了，但是对象还没有初始化
ctorInstance(memory); //2.初始化对象

解决

加volatile修饰

public class SafeDoubleCheckSingleton
{
    //通过volatile声明，实现线程安全的延迟初始化。
    private volatile static SafeDoubleCheckSingleton singleton;
    //私有化构造方法
    private SafeDoubleCheckSingleton(){
    }
    //双重锁设计
    public static SafeDoubleCheckSingleton getInstance(){
        if (singleton == null){
            //1.多线程并发创建对象时，会通过加锁保证只有一个线程能创建对象
            synchronized (SafeDoubleCheckSingleton.class){
                if (singleton == null){
                    //隐患：多线程环境下，由于重排序，该对象可能还未完成初始化就被其他线程读取
                                      //原理:利用volatile，禁止 "初始化对象"(2) 和 "设置singleton指向内存空间"(3) 的重排序
                    singleton = new SafeDoubleCheckSingleton();
                }
            }
        }
        //2.对象创建完毕，执行getInstance()将不需要获取锁，直接返回创建对象
        return singleton;
    }
}