【多线程-从零开始-伍】volatile关键字和内存可见性问题

简介: 【多线程-从零开始-伍】volatile关键字和内存可见性问题

volatile 关键字

import java.util.Scanner;  
  
public class Demo2 {  
    private static int n = 0;  
  
    public static void main(String[] args) {  
        Thread t1 = new Thread(() -> {  
            while(n == 0){  
                //啥都不写  
            }  
            System.out.println("t1 线程结束循环");  
        }, "t1");  
        Thread t2 = new Thread(() -> {  
            Scanner scanner = new Scanner(System.in);  
            System.out.println("请输入一个整数:");  
            n = scanner.nextInt();  
        }, "t2");        
        t1.start();  
        t2.start();  
    }
}
  • 当我们输入一个非 0 的数,理应 t1 中循环条件就不成立,将会打印“线程结束循环”,但实际上输入 1 后,t1 没有任何动静
  • 我们通过 jconsole 可以看到 t1 线程仍是持续工作的
  • 上述问题的原因,就是“内存可见性问题

内存可见性问题

层次 空间 速度 成本 数据
CPU 寄存器 掉电后丢失
内存 中等 中等 中等 掉电后丢失
硬盘 掉电后不丢失
while(n == 0) {
  
}
  • 上面代码中的这个操作,循环会执行非常多次,每次循环,都要执行一个n == 0这样的判定
  1. 从内存读取数据到寄存器中(读取内存,相比之下,这个操作的速度非常慢)
  2. 通过类似 cmp 指令,比较寄存器和 0 的值(这个指令执行速度非常快)
  • 此时 JVM 执行这个代码的过程的时候,发现:每次执行循环操作的开销非常大,并且每次执行的结果都是一样的
  • 并且JVM根被没有意识到,用户可能在未来会修改n,于是JVM就做了一个大胆的操作——直接把这个操作给优化掉了
  • 每次循环,不会重新读取内存中的数据,而是直接读取寄存器/cache 中的数据(缓存的结果)
  • JVM 做出上述决定之后,此时意味着循环的开销大幅度降低了,但当用户修改 n 的时候,内存中的 n 已经改变了,但是由于 t1 线程每次循环,不会真的读内存,所以感知不到 n 的改变
  • 内存中的 n 的改变,对于线程 t1 来说是“不可见的”,这样就引起了 bug
  • 内存可见性问题本质上是编译器/JVM 对代码进行优化的时候,优化出了 bug
  • 如果代码是单线程的,编译器/JVM 的代码优化一般都是非常准确的,优化之后,不会影响到逻辑
  • 但是代码如果是多线程的,编译器/JVM 的代码优化就可能出现误判(编译器/JVM 的 bug),导致不该优化的地方也给优化了,于是就造成了内存可见性问题

[!quote] 编译器问啥要做优化?

  • 有些程序员写出来的代码太低效了,为了能降低程序员的门槛,即使你的代码写的一般,最终执行也不会落下风
  • 因此一些主流的编译器,都会好引入优化机制(优化手段是多种多样的)
  • 优化就是编译器自动调整你写的代码,保持原有逻辑不变的前提下,提高代码的执行效率
  • 代码优化的效果是非常明显的

  • 若一个服务器在开启优化的时候启动时间为 10 min,那么在不开启优化的时候,启动时间可能会在 30 min+

若在 while 循环中加入一个 sleep 操作

while(n == 0) {
  Thread.sleep(10);
}
System.out.println("t1 线程结束循环");
//在输入1后,成功输出:"t1 线程结束循环"
  • 说明加入 sleep 之后,刚才谈到的针对读取 n 内存数据的优化操作不再进行了
  • 因为和读取内存相比,sleep 的开销更大,远远超过了读取内存,就算把读取内存的操作优化掉,也没有意义,杯水车薪

volatile 关键字的用法

  • volatile 关键字修饰一个变量,提示编译器说这个变量是“易变”的
  • 编译器进行上述优化的前提,是编译器认为,针对这个变量的频繁读取,结果都是固定的
  • 使用 volatile 关键字修饰变量之后,编译器就会禁止上述的优化,确保每次循环都是从内存中重新读取数据
private static volatile int n = 0;
  • 编译器的开发者,知道这个场景中可能出现误判,于是就把权限交给程序员,让程序员能够部分的干预到优化的进行
  • 引入 volatile 的时候,编译器生成这个代码的时候,就会给这个变量的读取操作附近生成一些特殊的指令,称为“内存屏障”,后续 JVM 执行到这些特殊指令,就知道不能进行上述优化了


volatile 只是解决内存可见性问题,不能解决原子性问题,如果两个线程针对同一个变量进行修改(count++),volatile 也无能为力


[!quote] 网络上“内存可见性”问题:

  • 工作内存(其实就是 CPU 的寄存器和 cache)
  • 主内存

  • 整个 Java 程序持有这个主内存,每个 Java 程序又有一份自己的工作内存
  • 像上述例子中的内存变量 n,本身是在主内存中,在 t1 和 t2 线程工作的过程中,就会把主内存的数据拷贝到>工作内存中
  • t2 如果修改了 n,先修改工作内存,再写回到主内存中。t1 读取 n 的时候,则是从主内存加载到工作内存,接下来的判定都是依照工作内存的值来进行判定的。此时 t2 修改了主内存,对于 t1 的工作内存未产生影响,从而出现了上述内存可见性问题


相关文章
|
3月前
|
存储 SQL 缓存
揭秘Java并发核心:深度剖析Java内存模型(JMM)与Volatile关键字的魔法底层,让你的多线程应用无懈可击
【8月更文挑战第4天】Java内存模型(JMM)是Java并发的核心,定义了多线程环境中变量的访问规则,确保原子性、可见性和有序性。JMM区分了主内存与工作内存,以提高性能但可能引入可见性问题。Volatile关键字确保变量的可见性和有序性,其作用于读写操作中插入内存屏障,避免缓存一致性问题。例如,在DCL单例模式中使用Volatile确保实例化过程的可见性。Volatile依赖内存屏障和缓存一致性协议,但不保证原子性,需与其他同步机制配合使用以构建安全的并发程序。
69 0
|
13天前
|
监控 Java 数据库连接
线程池在高并发下如何防止内存泄漏?
线程池在高并发下如何防止内存泄漏?
|
15天前
|
监控 Java 数据库连接
使用线程池时,如何避免内存泄漏的问题?
使用线程池时,如何避免内存泄漏的问题?
|
23天前
|
缓存 安全 Java
使用 Java 内存模型解决多线程中的数据竞争问题
【10月更文挑战第11天】在 Java 多线程编程中,数据竞争是一个常见问题。通过使用 `synchronized` 关键字、`volatile` 关键字、原子类、显式锁、避免共享可变数据、合理设计数据结构、遵循线程安全原则和使用线程池等方法,可以有效解决数据竞争问题,确保程序的正确性和稳定性。
33 2
|
2月前
|
存储 缓存 Java
java线程内存模型底层实现原理
java线程内存模型底层实现原理
java线程内存模型底层实现原理
|
15天前
|
监控 数据可视化 Java
如何使用JDK自带的监控工具JConsole来监控线程池的内存使用情况?
如何使用JDK自带的监控工具JConsole来监控线程池的内存使用情况?
|
2月前
|
监控 Java 数据库连接
使用线程池时,如何避免内存泄漏的问题?
使用线程池时,如何避免内存泄漏的问题?
|
2月前
|
Arthas 监控 Java
监控线程池的内存使用情况以预防内存泄漏
监控线程池的内存使用情况以预防内存泄漏
|
2月前
|
监控 数据可视化 Java
使用JDK自带的监控工具JConsole来监控线程池的内存使用情况
使用JDK自带的监控工具JConsole来监控线程池的内存使用情况
|
4月前
|
Java
JVM内存问题之jstack命令查看JVM线程快照如何解决
JVM内存问题之jstack命令查看JVM线程快照如何解决