Volatile与Java内存模型-51CTO.COM

被volatile修改的变量有2大特点

特点

可见性
有序性---排序要求，禁止重排

volatile的内存语义

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中。
当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，直接从主内存中读取。
所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取。

内存屏障

是什么

内存屏障（是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatile实现了Java内存模型中的可见性和有序性，但volatile无法保证原子性。

内存屏障之前的所有写操作都要回写到主内存，

内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。

因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。

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

面试中经常问到的，volatile凭什么可以保证可见性和有序性？？？靠的就是内存屏障 (Memory Barriers / Fences)

内存屏障的底层是什么?怎么实现的？

通过C++源码分析 Unsafe.class / Unsafe.java / Unsafe.cpp / OrderAccess.hpp /
orderAccess_linux_x86.inline.hpp 其底层依托的就是 cpu的四个屏障指令。(底层系统级别的指令)

happens-before 之 volatile 变量规则

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

JMM 就将内存屏障插⼊策略分为 4 种

写

在每个 volatile 写操作的前⾯插⼊⼀个 StoreStore 屏障
在每个 volatile 写操作的后⾯插⼊⼀个 StoreLoad 屏障

读

在每个 volatile 读操作的后⾯插⼊⼀个 LoadLoad 屏障
在每个 volatile 读操作的后⾯插⼊⼀个 LoadStore 屏障

volatile特性

保证可见性

保证不同线程对这个变量进行操作时的可见性，即变量一旦改变所有线程立即可见。

举个栗子

public class VolatileSeeDemo{
static boolean flag = true;       //不加volatile，没有可见性
//static volatile boolean flag = true;       //加了volatile，保证可见性

public static void main(String[] args){
	new Thread(() -> {
            System.out.println(Thread.currentThread().getName()+"\t come in");
            while (flag){

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

//暂停2秒钟后让main线程修改flag值
try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace();}

	flag = false;
    System.out.println("main线程修改完成");
    }
}

不加volatile，没有可见性，程序无法停止，加了volatile，保证可见性，程序可以停止。

原理解释：

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

问题可能:

1. 主线程修改了flag之后没有将其刷新到主内存，所以t1线程看不到。

2. 主线程将flag刷新到了主内存，但是t1一直读取的是自己工作内存中flag的值，没有去主内存中更新获取flag最新的值。

我们的诉求：

1.线程中修改了工作内存中的副本之后，立即将其刷新到主内存；

2.工作内存中每次读取共享变量时，都去主内存中重新读取，然后拷贝到工作内存。

解决：

使用volatile修饰共享变量，就可以达到上面的效果，被volatile修改的变量有以下特点：

1. 线程中读取的时候，每次读取都会去主内存中读取共享变量最新的值，然后将其复制到工作内存

2. 线程中修改了工作内存中变量的副本，修改之后会立即刷新到主内存

volatile变量的读写过程

前面学习JMM的时候我们已经了解了：关于主内存与工作内存之间具体的交互协议（即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节）

Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。现在我们结合volatile关键字再来看一下。

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

read: 作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存

load: 作用于工作内存，将read从主内存传输的变量值放入工作内存变量副本中，即数据加载

use: 作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作

assign: 作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作

store: 作用于工作内存，将赋值完毕的工作变量的值写回给主内存

write: 作用于主内存，将store传输过来的变量值赋值给主内存中的变量

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

lock: 作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程。

unlock: 作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用

不保证原子性

volatile变量的复合操作(如i++)不具有原子性

举个栗子

class MyNumber {
     volatile int number = 0;

    public void addPlusPlus() {
        number++;
    }
}

public class VolatileNoAtomicDemo {
    public static void main(String[] args) throws InterruptedException {
        MyNumber myNumber = new MyNumber();

        for (int i = 1; i <=10; i++) {
            new Thread(() -> {
                for (int j = 1; j <= 1000; j++) {
                    myNumber.addPlusPlus();
                }
            },String.valueOf(i)).start();
        }

        //暂停几秒钟线程
        try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
        System.out.println(Thread.currentThread().getName() + "\t" + myNumber.number);
    }
}

从i++的字节码角度说明

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。i++; 不具备原子性，该操作是先读取值，然后写回一个新值，相当于原来的值加上1，分3步完成

如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败，因此对于add方法必须使用synchronized修饰，以便保证线程安全。

结论

多线程环境下，"数据计算"和"数据赋值"操作可能多次出现，即操作非原子。若数据在加载之后，若主内存count变量发生修改之后，由于线程工作内存中的值在此前已经加载，从而不会对变更操作做出相应变化，即私有内存和公共内存中变量不同步，进而导致数据不一致。

对于volatile变量，JVM只是保证从主内存加载到线程工作内存的值是最新的，也就是数据加载时是最新的。由此可见volatile解决的是变量读时的可见性问题，但无法保证原子性，对于多线程修改共享变量的场景必须使用加锁同步。

面试题：为什么volatile不能保证原子性？

拿 i++的JVM的字节码，i++分成三步，工作内存和主内存之间进行读取写入的时候，在在use和assign之间依然有极小的间隙期，在间隙期的时候是非原子操作。

read-load-use 和 assign-store-write 成为了两个不可分割的原子操作，但是在use和assign之间依然有极小的一段真空期，有可能变量会被其他线程读取，导致数据出现错误。

无论在哪一个时间点主内存的变量和任一工作内存的变量的值都是相等的。这个特性也就导致了volatile变量不适合参与到依赖当前值的运算。

指令禁重排

说明

重排序

重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序

不存在数据依赖关系，可以重排序；
存在数据依赖关系，禁止重排序

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

重排序的分类和执行流程

编译器优化的重排序：编译器在不改变单线程串行语义的前提下，可以重新调整指令的执行顺序
指令级并行的重排序：处理器使用指令级并行技术来讲多条指令重叠执行，若不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序
内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是乱序执行

数据依赖性：若两个操作访问同一变量，且这两个操作中有一个为写操作，此时两操作间就存在数据依赖性。

存在数据依赖关系，禁止重排序===> 重排序发生，会导致程序运行结果不同。

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

底层实现是通过内存屏障

四大屏障的插入情况

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

StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作都已经刷新到主内存中。

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

StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序

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

LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。

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

LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。

如何正确使用volatile

单一赋值可以，but含复合运算赋值不可以(i++之类)

volatile int a = 10
volatile boolean flag = false

状态标志，判断业务是否结束
开销较低的读，写锁策略

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

	private volatile int value;

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

}