一、被Volatile修改的变量有2大特点
1. 特点
可见性
写完后立即刷新回主内存并及时发出通知,其它线程可以去主内存拿到最新的数据,前面的修改对后面所有线程可见
有序性
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段,有时候会改变程序语句的先后顺序,若不存在数据依赖关系,可以重排序;存在数据依赖关系,禁止重排序;但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
注意:volatile 修饰的字段,没有原子性
2. volatile的内存语义
- 当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中
- 当读一个volatile变量时,JMM会把该线程对应的本地内存设置为无效,重新回到主内存中读取最新共享变量的值
- 所以volatile的写内存语义是直接刷新到主内存中,读的内存语义是直接从主内存中读取
volatile凭什么可以保证可见性和有序性?
内存屏障Memory Barrier
二、内存屏障
1. 什么是内存屏障
内存屏障(也称内存栅栏,内存栅障,屏障指令等,是一类同步屏障指令,是CPU或编译器在对内存随机访问的操作中的一个同步点,使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作),避免代码重排序。内存屏障其实就是一种JVM指令,Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令,通过这些内存屏障指令,volatile实现了Java内存模型中的可见性和有序性,但volatile无法保证原子性。
内存屏障之前的所有写操作都要回写到主内存,
内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
因此重排序时,不允许把内存屏障之后的指令重排序到内存屏障之前。
一句话:对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读,也叫写后读。
2. 内存屏障分类
2.1 分类解析
内存屏障粗分为两种
- 读屏障(Load Barrier):在读指令之前插入读屏障,让工作内存或CPU高速缓存 当中的缓存数据失效,重新回到主内存中获取最新数据。
- 写屏障(Store Barrier):在写指令之后插入写屏障,强制把缓冲区的数据刷回到主内存中。
内存屏障细分四种:
屏障类型 | 指令示例 | 说明 |
---|---|---|
LoadLoad | Load1;LoadLoad;Load2 | 保证Load1的读取操作在Load2及后续读取操作之前执行 |
StoreStore | Store1;StoreStore;Store2 | 在store2及其后的写操作执行前,保证Store1的写操作已经刷新到主内存 |
LoadStore | Load1;LoadStore;Store2 | 在Store2及其后的写操作执行前,保证Load1的读操作已经结束 |
StoreLoad | Store1;StoreLoad;Load2 | 保证Store1的写操作已经刷新到主内存后,Load2及其后的读操作才能执行 |
2.2 源码分析
IDEA工具里面找 Unsafe.class
–> Unsafe.java
–> Unsafe.cpp
–> OrderAccess.hpp
–> orderAccess_linux_x86.inline.hpp
- Unsafe.class
- Unsafe.java
- Unsafe.cpp
- OrderAccess.hpp
- orderAccess_linux_x86.inline.hpp
3. volatile 变量规则与插入策略
3.1 如何保证有序性?
通过内存屏障禁重排
- 重排序有可能影响程序的执行和实现,因此,我们有时候希望JVM不要自动重排序。
- 对于编译器的重排序,JMM会根据重排序的规则,禁止特定类型的编译器重排序
- 对于处理器的重排序,Java编译器在生成指令序列的适当位置,插入内存屏障指令,来禁止特定类型的处理器排序。
3.2 happens-before 之 volatile 变量规则
- 当第一个操作为volatile读时,不论第二个操作是什么,都不能重排序。这个操作保证了volatile读之后的操作不会被重排到volatile读之前。
- 当第二个操作为volatile写时,不论第一个操作是什么,都不能重排序。这个操作保证了volatile写之前的操作不会被重排到volatile写之后。
- 当第一个操作为volatile写时,第二个操作为volatile读时,不能重排。
3.3 内存屏障插⼊策略
JMM 就将内存屏障插⼊策略分为 4 种
读屏障
在每个 volatile 读操作的后⾯插⼊⼀个 LoadLoad 屏障
LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。
在每个 volatile 读操作的后⾯插⼊⼀个 LoadStore 屏障
LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。
写屏障
在每个 volatile 写操作的前⾯插⼊⼀个 StoreStore 屏障
StoreStore屏障可以保证在volatile写之前,其前面的所有普通写操作都已经刷新到主内存中。
在每个 volatile 写操作的后⾯插⼊⼀个 StoreLoad 屏障
StoreLoad屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序
三、volatile特性
1. 保证可见性
保证不同线程对某个变量完成操作后结果及时可见,即该共享变量一旦改变所有线程立即可见
1.1 代码示例:
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) {
new Integer(308);
}
System.out.println("t1 over");
}, "t1").start();
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
new Thread(() -> {
flag = false;
}, "t2").start();
}
}
- 不加volatile,没有可见性,程序无法停止
- 加了volatile,保证可见性,程序可以停止
1.2 原理解析
线程t1中为何看不到被主线程main修改为false的flag的值?
猜测:
- 主线程修改了flag之后没有将其刷新到主内存,所以t1线程看不到。
- 主线程将flag刷新到了主内存,但是t1一直读取的是自己工作内存中flag的值,没有去主内存中更新获取flag最新的值。
诉求:
- 线程中修改了工作内存中的副本之后,立即将其刷新到主内存
- 工作内存中每次读取共享变量时,都去主内存中重新读取,然后拷贝到工作内存
使用 volatile
修饰共享变量,就可以达到上面的效果,被 volatile
修改的变量有以下特点:
- 线程中读取的时候,每次读取都会去主内存中读取共享变量最新的值,然后将其复制到工作内存
- 线程中修改了工作内存中变量的副本,修改之后会立即刷新到主内存
1.3 volatile变量的读写过程
Java内存模型中定义的8种工作内存与主内存之间的原子操作
read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→lock(锁定)→unlock(解锁)
read: 作用于主内存,将变量的值从主内存传输到工作内存,主内存到工作内存
load: 作用于工作内存,将read从主内存传输的变量值放入工作内存变量副本中,即数据加载
use: 作用于工作内存,将工作内存变量副本的值传递给执行引擎,每当JVM遇到需要该变量的字节码指令时会执行该操作
assign: 作用于工作内存,将从执行引擎接收到的值赋值给工作内存变量,每当JVM遇到一个给变量赋值字节码指令时会执行该操作
store: 作用于工作内存,将赋值完毕的工作变量的值写回给主内存
write: 作用于主内存,将store传输过来的变量值赋值给主内存中的变量
由于上述只能保证单条指令的原子性,针对多条指令的组合性原子保证,没有大面积加锁,所以,JVM提供了另外两个原子指令:
lock: 作用于主内存,将一个变量标记为一个线程独占的状态,只是写时候加锁,就只是锁了写变量的过程。
unlock: 作用于主内存,把一个处于锁定状态的变量释放,然后才能被其他线程占用
2. 没有原子性
volatile变量的符合操作不具有原子性
对于voaltile变量具备可见性,JVM只是保证从主内存加载到线程工作内存的值是最新的,也仅仅是数据加载时是最新的。但是多线程环境下,“数据计算”和“数据赋值”操作可能多次出现,若数据在加载之后,若主内存volatile修饰变量发生修改之后,线程工作内存的操作将会作废去读主内存最新值,操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步,进而导致数据不一致。由此可见volatile解决的是变量读时的可见性问题,但无法保证原子性,对于多线程修改主内存共享变量的场景必须加锁同步。
至于怎么去理解这个写丢失的问题,就是再将数据读取到本地内存到写回主内存中有三个步骤:数据加载—->数据计算—->数据赋值,如果第二个线程在第一个线程读取旧值与写回新值期间读取共享变量的值,那么第二个线程将会与第一个线程一起看到同一个值,并执行自己的操作,一旦其中一个线程对volatile修饰的变量先行完成操作刷回主内存后,另一个线程会作废自己的操作,然后重新去读取最新的值再进行操作,这样的话,它自身的那一次操作就丢失了,这就造成了 线程安全失败,因此,这个问题需要使用synchronized修饰以保证线程安全性。
读取赋值一个volatile变量的情况
read-load-use 和 assign-store-write 成为了两个不可分割的原子操作,但是在use和assign之间依然有极小的一段真空期,有可能变量会被其他线程读取,导致写丢失一次。无论在哪一个时间点主内存的变量和任一工作内存的变量的值都是相等的。这个特性就导致了volatile变量不适合参与到依赖当前值的运算,如i = i + 1; i++;之类的那么依靠可见性的特点volatile可以用在哪些地方呢? 通常volatile用做保存某个状态的boolean值or int值。
结论:volatile变量不适合参与到依赖当前值的运算,如i++,i=i+1之类的,通常用来保存某个状态的boolean值或者int值,也正是由于volatile变量只能保证可见性,在不符合以下规则的运算场景中,我们仍然要通过加锁来保证原子性:
运算结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值
变量不需要与其他的状态变量共同参与不变约束
volatile不具备原子性的代码示例
class MyNumber1 {
public volatile int num = 0;
public void addNum() {
num++;
}
}
public class VolatileDemo {
public static void main(String[] args) throws InterruptedException {
MyNumber1 myNumber1 = new MyNumber1();
for (int i = 0; i < 10; i++) {
new Thread(() -> {
for (int j = 0; j < 1000; j++) {
myNumber1.addNum();
}
}, "t" + i).start();
}
TimeUnit.SECONDS.sleep(3);
System.out.println("执行结束,num值为:" + myNumber1.num);
}
}
执行结果:
执行结束,num值为:9913
多次执行,结果都接近10000,但是到不了10000,原因在于上面说的,volatile修饰的变量,在多线程并发修改情况下会出现写丢失。
解决方式: 给 addNum() 添加 synchronized
public synchronized void addNum() {
num++;
}
3. 指令禁重排
3.1 重排序
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段,有时候会改变程序语句的先后顺序
- 不存在数据依赖关系,可以重排序;
- 存在数据依赖关系,禁止重排序
但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
3.2 重排序的分类和执行流程
- 编译器优化的重排序:编译器在不改变单线程串行语义的前提下,可以重新调整指令的执行顺序
- 指令级并行的重排序:处理器使用指令级并行技术来讲多条指令重叠执行,若不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序
- 内存系统的重排序:由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是乱序执行
3.3 数据依赖性
若两个操作访问同一变量,且这两个操作中有一个为写操作,此时两操作间就存在数据依赖性。
案例说明
不存在数据依赖关系,可以重排序
重排前 重排后 int a = 1; //1
int b = 20; //2
int c = a + b; //3int b = 20; //1
int a = 1; //2
int c = a + b; //3结论:编译器调整了语句的顺序,但是不影响程序的最终结果。 可以重排序 存在数据依赖关系,禁止重排序
重排序发生,会导致程序运行结果不同。编译器和处理器在重排序时,会遵守数据依赖性,不会改变存在依赖关系的两个操作的执行,但不同处理器和不同线程之间的数据性不会被编译器和处理器考虑,其只会作用于单处理器和单线程环境,下面三种情况,只要重排序两个操作的执行顺序,程序的执行结果就会被改变。
四、如何正确使用volatile
1. 单一赋值
单一赋值可以,但是含复合运算赋值不可以(i++之类)
volatile int a = 10
volatile boolean flag = false
2. 状态标志
判断业务是否结束
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) {
new Integer(308);
}
System.out.println("t1 over");
}, "t1").start();
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
new Thread(() -> {
flag = false;
}, "t2").start();
}
}
3. 开销较低的读,写锁策略
class MyNumber1 {
public volatile int num = 0;
public synchronized void addNum() {
num++;
}
}
public class VolatileDemo {
public static void main(String[] args) throws InterruptedException {
MyNumber1 myNumber1 = new MyNumber1();
for (int i = 0; i < 10; i++) {
new Thread(() -> {
for (int j = 0; j < 1000; j++) {
myNumber1.addNum();
}
}, "t" + i).start();
}
TimeUnit.SECONDS.sleep(3);
System.out.println("执行结束,num值为:" + myNumber1.num);
}
}
4. DCL双端锁的发布
4.1 问题代码示例
public class SafeDoubleCheckSingleton {
// 加 volatile 保证了对象的可见性
// private volatile static SafeDoubleCheckSingleton singleton = null;
// 不加 volatile 在多线程环境下可能导致获取到的对象是null
private static SafeDoubleCheckSingleton singleton = null;
//私有化构造方法
private SafeDoubleCheckSingleton() {
}
//双重锁设计
public static SafeDoubleCheckSingleton getInstance() {
if (singleton == null) {
//1.多线程并发创建对象时,会通过加锁保证只有一个线程能创建对象
synchronized (SafeDoubleCheckSingleton.class) {
if (singleton == null) {
//隐患:多线程环境下,由于重排序,该对象可能还未完成初始化就被其他线程读取
singleton = new SafeDoubleCheckSingleton();
}
}
}
//2.对象创建完毕,执行getInstance()将不需要获取锁,直接返回创建对象
return singleton;
}
public static void main(String[] args) {
SafeDoubleCheckSingleton instance = SafeDoubleCheckSingleton.getInstance();
}
}
4.2 问题如下
单线程环境下:(或者说正常情况下),在”问题代码处”,会执行如下操作,保证能获取到已完成初始化的实例
由于代码从编译到执行的过程中,可能会出现指令重排,2、3 两处的指令执行顺序可能会颠倒,这就有可能导致返回的对象,还未执行初始化。
多线程环境下:在”问题代码处”,会执行如下操作,由于重排序导致2,3乱序,后果就是其他线程得到的是null而不是完成初始化的对象
正确的执行顺序
异常的执行顺序
4.3 问题解决
4.3.1 方式一:加volatile修饰
原理:利用volatile,禁止 “初始化对象”(2) 和 “设置singleton指向内存空间”(3) 的重排序
public class SafeDoubleCheckSingleton {
// 加 volatile 保证了对象的可见性,实现线程安全的延迟初始化。
private volatile static SafeDoubleCheckSingleton singleton = null;
//私有化构造方法
private SafeDoubleCheckSingleton() {
}
//双重锁设计
public static SafeDoubleCheckSingleton getInstance() {
if (singleton == null) {
//1.多线程并发创建对象时,会通过加锁保证只有一个线程能创建对象
synchronized (SafeDoubleCheckSingleton.class) {
if (singleton == null) {
//隐患:多线程环境下,由于重排序,该对象可能还未完成初始化就被其他线程读取
singleton = new SafeDoubleCheckSingleton();
}
}
}
//2.对象创建完毕,执行getInstance()将不需要获取锁,直接返回创建对象
return singleton;
}
public static void main(String[] args) {
SafeDoubleCheckSingleton instance = SafeDoubleCheckSingleton.getInstance();
}
}
4.3.2 方式二:采用静态内部类的方式实现
public class SingletonDemo {
private SingletonDemo() {
}
private static class SingletonDemoHandler {
private static SingletonDemo instance = new SingletonDemo();
}
public static SingletonDemo getInstance() {
return SingletonDemoHandler.instance;
}
}
五、总结
凭什么我们java写了一个volatile关键字系统底层加入内存屏障?两者关系怎么勾搭上的?
字节码层面
它其实给 volatile 修饰的字段添加了一个
ACC_VOLATILE
标识查看命令:
javap -v -p SafeDoubleCheckSingleton.class
JVM 在把字节码 生成 为 机器码 的时候,发现操作是 volatile 的变量的话,就会根据 JMM 要求,在相应的位置去插入 内存屏障指令
对比 java.util.concurrent.locks.Lock 来理解
cpu执行机器码指令的时候,是使用lock前缀指令 来实现 volatile 的功能的。
Lock 指令,相当于内存屏障,功能也类似内存屏障的功能:
- 首先对总线/缓存加锁,然后去执行后面的指令,最后,释放锁,同时把高速缓存的数据刷新回到主内存
- 在 lock 锁住总线/缓存的时候,其它 cpu 的读写请求就会被阻塞,直到锁释放。Lock过后的写操作,会让其它cpu的高速缓存中相应的数据失效这样后续这些 cpu 在读取数据的时候,就会从主内存去加载最新的数据
加了 Lock 指令过后的具体表现,就跟 JMM 添加内存屏障后一样。
一句话总结
- volatile写之前的的操作,都禁止重排到volatile之后
- volatile读之后的操作,都禁止重排到volatile之前
- volatile写之后volatile读,禁止重排序
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 george_95@126.com