JVM—内存可见性

本文介绍了Java内存模型(JMM)中的可见性概念,强调了共享变量在线程间的可见性问题。synchronized和volatile都是解决可见性的方式,但synchronized还能保证原子性。volatile通过内存屏障防止重排序,确保变量的即时可见性,但无法保证复合操作的原子性。总结中提到,final关键字也能保证内存可见性,并对比了synchronized和volatile的差异。
摘要由CSDN通过智能技术生成

原文地址:内存可见性

什么是可见性

  • 可见性:一个线程对共享变量值的修改,能够及时地被其他线程看到
  • 共享变量:如果一个变量在多个线程的工作内存中都存在副本,那么这个变量就是这几个线程的共享变量

Java内存模型(JMM)的介绍

Java内存模型(Java Memory Model)描述了Java程序中各种变量(共享变量)的访问规则,及在JVM中将变量存储到内存和从内存中读取出变量的底层细节

  1. 所有的变量都存储在主内存中
  2. 每个线程都有自己独立的工作内存,里面保存该线程使用到的变量的副本(主内存中该变量的一份拷贝)

Java内存模型(JMM)两条规定

  1. 线程对共享变量的所有操作都必须在自己的工作内存中进行,不能直接从主内存中读取
  2. 不同线程之间无法直接访问其他线程工作内存中的变量,线程间变量值的传递需要通过主内存来完成

JMM中共享变量可见性实现的原理

线程1对共享变量的修改要想被线程2及时看到,必须要经过如下2个步骤:

  1. 把工作内存1中更新过的共享变量刷新到主内存中
  2. 将主内存中最新的共享变量的值更新到工作内存2中

要实现共享变量的可见性,必须保证两点

  • 线程修改后的共享变量值能够及时从工作内存中刷新到主内存中
  • 其他线程能够及时把共享变量的最新值从主内存更新到自己的工作内存中

synchronized实现可见性

  1. 原子性(同步)
  2. 可见性

JMM关于synchronized的两条规定

  1. 线程解锁前,必须把共享变量的最新值刷新到主内存中
  2. 线程加锁时,将清空工作内存中共享变量的值,从而使用共享变量时需要从主存中重新读取最新的值(注意:加锁与解锁需要是同一把锁)线程解锁前对共享变量的修改在下次加锁时对其他线程可见

线程执行互斥代码的过程

  • 1.获得互斥锁
  • 2.清空工作内存
  • 3.从主内存拷贝变量的最新副本到工作内存
  • 4.执行代码
  • 5.将更改后的共享变量的值刷新到主内存中
  • 6.释放互斥锁

重排序的介绍:代码书写的顺序与实际执行的顺序不同,指令重排序是编译器或处理器为了提高程序性能而做的优化

  1. 编译器优化的重排序(编译器优化)
  2. 指令级并行重排序(处理器优化)
  3. 内存系统的重排序(处理器优化)

as-if-serial的介绍:无论如何重排序,程序执行结果应与代码顺序执行结果一致(Java编译器,运行时和处理器都会保证Java在单线程下遵循as-if-serial语义)

int num1 = 1; //第1行代码
int num2 = 2; //第2行
int sum = num1 + num2; //第3行

单线程:第1,2行的顺序可以重排,但第3行不能,重排序不会给单线程带来内存可见性问题,多线程中程序交错执行时,重排序可能会造成内存可见性问题

导致共享变量在线程间不可见的原因及synchronized解决方案

  • 1.线程的交叉执行——>原子性(synchronized的同步性)
  • 2.重排序结合线程交叉执行——>原子性
  • 3.共享变量更新后的值没有在工作内存与主内存间及时更新——>可见性

volatile实现可见性

  1. 能够保证volatile变量的可见性
  2. 不能保证volatile变量复合操作的原子

volatile如何实现内存的可见性

深入来说:通过加入内存屏障和禁止重排序优化来实现的

  1. 对volatile变量执行写操作时,会在写操作后加入一条store屏障指令
  2. 对volatile变量执行读操作时,会在读操作前加入一条load屏障指令

通俗地讲:volatile变量在每次被线程访问时,都强迫从主内存中重读该变量的值,而当该变量发生变化时,又会强迫将最新的值刷新到主内存,这样任何时刻,不同的线程总能看到该变量的最新值

线程读写volatile变量的过程的总结

线程写volatile变量的过程

  • 1.改变线程工作内存中volatile变量副本的值
  • 2.将改变后的副本的值从工作内存刷新到主内存

线程读volatile变量的过程

  • 1.从主内存中读取volatile变量的最新值到线程的工作内存中
  • 2.从工作内存中读取volatile变量的副本

volatile不能保证volatile变量复合操作的原子性

原子性:每次只有一条线程能执行锁内代码

private int number = 0;
number++;//不是原子操作
  1. 读取number的值
  2. 将number的值加1
  3. 写入最新的number的值
synchronized(this) {
    number++;//加入synchronized,变为原子操作
}
private volatile int number=0;//变为volatile变量,无法保证原子性

volatile不能保证volatile变量复合操作的原子性,解决方案如下:

  1. 使用synchronized关键字
  2. 使用ReentrantLock关键字(java.util.concurrent.locks包下)
  3. 使用AtomicInterger(java.util.concurrent.atomic包下)

//使用ReentrantLock锁保证操作的原子性:

private Lock lock = new ReentrantLock();

lock.lock();
try{
    this.number++;
}finally{
    lock.unlock();//释放锁
}

要在多线程中安全的使用volatile变量,必须同时满足

  1. 对变量的写入操作不依赖其当前值,不满足:number++,count=count*5等,满足:boolean变量,记录温度变化的变量等
  2. 该变量没有包含在具体其他变量的不变式中,不满足:不变式low<up

总结

final也可以保证内存的可见性

synchronized和volatile比较

  • volatile不需要加锁,比synchronized更轻量级,不会阻塞线程
  • 从内存可见性角度讲,volatile读相当于加锁,volatile写相当于解锁
  • synchronized既能保证可见性,又能保证原子性,而volatile只能保证可见性,无法保证原子性

即使没有使用保证可见性的操作,很多时候共享变量都依然可以在主内存和工作内存中得到及时的更新的原因:一般只有在短时间内高并发的情况下才会出现变量得不到及时更新的情况,因为CPU在执行时间时会很快的刷新缓存,所以一般情况下很难看到这种问题

当程序中有一个long或double类型的变量,而且该变量也没有任何关键字修饰,那么此时对64位的long,double变量的读写就不是原子操作,即可以分解。因为java内存模型允许JVM将没有被volatile修饰的64位数据类型的读写操作划分为两次32位的读写操作来进行,就可能导致多线程并发访问该变量时,出现只读了一半就被抢走资源进而导致数据异常的问题,解决方法是在long,double类型的变量上加入volatile关键字不过大部分虚拟机已经把long,double类型的变量对其进行一些保护,因此在实际编程中也不需刻意为long,double类型的数据加上volatile关键字

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值