volatile与JMM
volatile与JMM
volatile修改的变量有两大特点
-
可见性
写完后立即刷新回主内存并及时发出通知
,大家可以去主内存拿最新版,前面的修改对后面所有线程可见 -
有序性(禁重排)
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段,有时候会改变程序语句的先后顺序不存在数据依赖关系,可以重排序;存在数据依赖关系,禁止重排序
;但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
volatile的内存语义
-
当写一个volatile变量时,JMM会把该线程对应的本地内存中的共享变量立即刷新回到主内存中。
-
当读一个volatile变量时,JMM会把该线程对应的工作内存设置为无效,直接从主内存中读取共享变量。
-
所以volatile的写内存语义是直接刷新到主内存中,读的内存语义是直接从主内存中读取。
内存屏障
概述
内存屏障(也称内存栅栏,内存栅障,屏障指令等,是一类同步屏障指令,是CPU或编译器在对内存随机访问的操作中的一个同步点,使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作),避免代码重排序。内存屏障其实就是一种JVM指令,Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令
,通过这些内存屏障指令,volatile实现了Java内存模型中的可见性和有序性,但volatile无法保证原子性
。
内存屏障之前的所有写操作都要回写到主内存
内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
写屏障(Store Memory Barrier)
:告诉处理器在写屏障之前将所有存储在缓存(store buffer es) 中的数据同步到主内存。也就是说当看到Store屏障指令, 就必须把该指令之前所有写入指令执行完毕才能继续往下执行。
读屏障(Load Memory Barrier)
:处理器在读屏障之后的读操作, 都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。
因此重排序时,不允许把内存屏障之后的指令重排序到内存屏障之前。一句话:对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读,也叫写后读。
内存屏障分类
粗分两种
-
写屏障
在写指令之后插入写屏障,强制把写缓冲区的数据刷回到主内存中 -
读屏障
在读指令之前插入读屏障,让工作内存或CPU高速缓存当中的缓存数据失效,重新回到主内存中获取最新数据
细分4种
Unsafe.class
文件
public native void loadFence();
public native void storeFence();
public native void fullFence();
C++源码分析:Unsafe.java
/**
* Ensures lack of reordering of loads before the fence
* with loads or stores after the fence.
* @since 1.8
*/
public native void loadFence();
/**
* Ensures lack of reordering of stores before the fence
* with loads or stores after the fence.
* @since 1.8
*/
public native void storeFence();
/**
* Ensures lack of reordering of loads or stores before the fence
* with loads or stores after the fence.
* @since 1.8
*/
public native void fullFence();
Unsafe.cpp
:可以看到方法内调用了acquire()、release()、fence()
方法,在OrderAccess
文件中
UNSAFE_ENTRY(void, Unsafe_LoadFence(JNIEnv *env, jobject unsafe))
UnsafeWrapper("Unsafe_LoadFence");
OrderAccess::acquire();
UNSAFE_END
UNSAFE_ENTRY(void, Unsafe_StoreFence(JNIEnv *env, jobject unsafe))
UnsafeWrapper("Unsafe_StoreFence");
OrderAccess::release();
UNSAFE_END
UNSAFE_ENTRY(void, Unsafe_FullFence(JNIEnv *env, jobject unsafe))
UnsafeWrapper("Unsafe_FullFence");
OrderAccess::fence();
UNSAFE_END
OrderAccess.hpp
:看到了上面提到的三个方法,同时上面又出现了loadload()、storestore()、loadstore()、storeload()
四种屏障
orderAccess_linux_x86.inline.hpp
:结合底层 linux 源码,发现读 loadload() 占用的是 acquire() 方法,方法内部区分 cpu 为 AMD64的处理方法和其他 cpu 处理方法
四种屏障
什么叫保证有序性
禁止指令重排,通过内存屏障禁止重排
-
重排序有可能影响程序的执行和实现, 因此, 我们有时候希望告诉JVM你别“自作聪明”给我重排序, 我这里不需要排序, 听主人的。
-
对于编译器的重排序, JMM会根据重排序的规则, 禁止特定类型的编译器重排序。
-
对于处理器的重排序, Java编译器在生成指令序列的适当位置, 插入内存屏障指令, 来禁止特定类型的处理器排序。
happens-before之volatile变量规则
JMM就将内存屏障插入策略分为四种规则
-
读屏障
在每个volatile
读操作的后面插入一个LoadLoad
屏障,禁止处理器把上面的volatile读与下面的普通读重排序。在每个
volatile
读操作的后面插入一个LoadStore
屏障,禁止处理器把上面的volatile读与下面的普通写重排序。
-
写屏障
在每个volatile
写操作的前面插入一个StoreStore
屏障,可以保证在volatile写之前
,其前面的所有普通写操作都已经刷新到主内存中。在每个
volatile
写操作的后面插入一个StoreLoad
屏障,作用是避免volatile写
与后面可能有的volatile读/写操作重排序
volatile特性
保证可见性
保证不同线程对某个变量完成操作后结果及时可见,即该共享变量一旦改变所有线程立即可见。
public class VolatileSeeDemo {
// 加了volatile,保证可见性程序就会正常停止,不加程序不停止一直循环
static volatile boolean flag = true;
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();
//暂停几秒
try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }
flag = false;
System.out.println("main线程修改完成, flag:" + flag);
}
}
上述代码原理解释
-
线程t1 中为何看不到被主线程main修改为false的flag的值?
-
主线程修改了flag之后没有将其刷新到主内存,所以t1线程看不到。
-
主线程将flag刷新到了主内存,但是t1一直读取的是自己工作内存中flag的值,没有去主内存中更新获取flag最新的值。
-
-
我们的诉求:
-
线程中修改了工作内存中的副本之后,立即将其刷新到主内存;
-
工作内存中每次读取共享变量时,都去主内存中重新读取,然后拷贝到工作内存。
-
-
解决:使用
volatile
修饰共享变量,就可以达到上面的效果,被volatile修改的变量有以下特点-
线程中读取的时候,每次读取都会去主内存中读取共享变量最新的值 ,然后将其复制到工作内存
-
线程中修改了工作内存中变量的副本,修改之后会立即刷新到主内存
-
volatile变量的读写过程
read(读取)→load(加载)→use(使用)→assign(赋值)→store(存储)→write(写入)→lock(锁定)→unlock(解锁)
read
: 作用于主内存,将变量的值从主内存传输到工作内存,主内存到工作内存
load
: 作用于工作内存,将read从主内存传输的变量值放入工作内存变量副本中,即数据加载
use
: 作用于工作内存,将工作内存变量副本的值传递给执行引擎,每当JVM遇到需要该变量的字节码指令时会执行该操作
assign
: 作用于工作内存,将从执行引擎接收到的值赋值给工作内存变量,每当JVM遇到一个给变量赋值字节码指令时会执行该操作
store
: 作用于工作内存,将赋值完毕的工作变量的值写回给主内存
write
: 作用于主内存,将store传输过来的变量值赋值给主内存中的变量
由于上述6条只能保证单条指令的原子性,针对多条指令的组合性原子保证,没有大面积加锁,所以,JVM提供了另外两个原子指令:
lock
: 作用于主内存,将一个变量标记为一个线程独占的状态,只是写时候加锁,就只是锁了写变量的过程。
unlock
: 作用于主内存,把一个处于锁定状态的变量释放,然后才能被其他线程占用
没有原子性
代码演示:如果方法上加了 synchronized
就可以保证原子性, 如果不加,只是给变量添加了 volatile
是无法保证原子性的,volatile只保证了可见性和有序性
class MyNumber {
volatile int number = 0;
public void addPlusPlus() {
number++;
}
}
/**
* @author zjh
*/
public class VolatileNoAtomicDemo {
public static void main(String[] args) {
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(2); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println(myNumber.number);
}
}
读取赋值一个普通变量的情况
当线程1对主内存对象发起read操作到write操作第一套流程的时间里,线程2随时都有可能对这个主内存对象发起第二套操作,各忙各的
不保证原子性
对于volatile
变量具备可见性 ,JVM
只是保证从主内存加载到线程工作内存的值是最新的,也仅是数据加载时是最新的
。但是多线程环境下,“数据计算”和“数据赋值”操作可能多次出现,若数据在加载之后,若主内存volatile
修饰变量发生修改之后,线程工作内存中的操作将会作废去读主内存最新值,操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步
,进而导致数据不一致。由此可见volatile解决的是变量读取时的可见性问题,但无法保证原子性,对于多线程修改主内存共享变量的场景必须使用加锁同步。
大白话:A在加载或者计算或者是赋值的时候,B已经提交了,那么A就要获取最新的了,前面的操作也会随之失效了
加上 synchronized
加上 synchronized 报成了原子性,线程就会一个一个进来,就不会导致操作失效了
加上 volatile
volatile 不能保证原子性,大家一起读,一起加一,就看谁提交的快了。提交快的直接让另一个失效
从i++的字节码角度说明
原子性指的是一个操作是不可中断的,即使是在多线程环境下,一个操作一旦开始就不会被其他线程影响。
public void add(){
i++; //不具备原子性,该操作是先读取值,然后写回一个新值,相当于原来的值加上1,分3步完成
}
如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值
,那么第二个线程就会与第一个线程一起看到同一个值,并执行相同值的加1操作,这也就造成了线程安全失败,因此对于add方法必须使用synchronized修饰,以便保证线程安全.
结论
volatile不适合参与到依赖当前值的运算,如i=i+1,i++之类的,通常volatile用作保存某个状态的boolean值或or int值。 (一旦布尔值被改变迅速被看到,就可以做其他操作)
由于volatile变量只能保证可见性,在不符合以下两条规则的运算场景中,我们仍然要通过加锁(使用synchronized、java.util.concurrent中的锁或原子类)来保证原子性:
- 运算结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值。
- 变量不需要与其他的状态变量共同参与不变约束。
指令禁重排
重排序
重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段,有时候会改变程序语句的先后顺序不存在数据依赖关系,可以重排序;存在数据依赖关系 ,禁止重排序。但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
重排序的分类和执行流程
- 编译器优化的重排序: 编译器在不改变单线程串行语义的前提下,可以重新调整指令的执行顺序
- 指令级并行的重排序: 处理器使用指令级并行技术来讲多条指令重叠执行,若不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序
- 内存系统的重排序: 由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是乱序执行
数据依赖性:若两个操作访问同一变量,且这两个操作中有一个为写操作,此时两操作间就存在数据依赖性
案列
-
不存在数据依赖关系,可以重排序 ===> 重排序OK,随便重排都没问题
-
存在数据依赖关系,禁止重排序 ===> 重排序发生,会导致程序运行结果不同
volatile的底层实现是通过内存屏障,2次复习
-
volatile有关的禁止指令重排的行为
-
四大屏障的插入情况
案例
public class VolatileTest {
int i = 0;
volatile boolean flag = false;
public void write(){
i = 2;
flag = true;
}
public void read(){
if(flag){
System.out.println("---i = " + i);
}
}
}
如何正确使用volatile
单一赋值可以,含有符合运算赋值不可以(比如i++)
-
volatile int a = 10
-
volatile boolean flag = false
状态标志,判断业务是否结束
/**
* @author zjh
*
* 使用: 作为一个布尔状态标志,用于指示发生了一个重要的一次性事件,例如完成初始化或任务结束
* 理由: 状态标志并不低赖于程序内任何其他状态,且通常只有一种状态转换
* 例子: 判断业务是否结束
*/
public class UseVolatileDemo {
private volatile static boolean flag = true;
public static void main(String[] args) {
new Thread(() -> {
while (flag) {
// 循环...
}
}, "t1").start();
// 暂停几秒钟线程
try {TimeUnit.SECONDS.sleep(2);} catch (InterruptedException e) {throw new RuntimeException(e);}
new Thread(() -> {
flag = false;
}, "t2").start();
}
}
开销较低的读,写锁策略
当读远多于写,最安全的方法就是加两个synchronized,这样的话锁的粒度会很大。可以读用volatile,写用synchronized可以提高性能。
/**
* 使用:当读远多于写,结合使用内部锁和volatile变量来减少同步的开销
* 理由:利用volatile保证读取操作的可见性,利用synchronized保证复合操作的原于性
*/
public class Counter {
private volatile int value;
public int getValue() {
return value; //利用volatile保证读取操作的可见性
}
public synchronized int setValue() {
return value++; //利用synchronized保证复合操作的原子性
}
}
DCL双锁案例
public class SafeDoubleCheckSingleton {
private static SafeDoubleCheckSingleton singleton;
/**
* 私有化构造方法
*/
private SafeDoubleCheckSingleton(){
}
/**
* 双重锁
* @return 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(){
}
/**
* 双重锁
* @return 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;
}
}
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· .NET10 - 预览版1新功能体验(一)