volatile的功能
- 保证内存可见性
- 禁止指令重排序
内存可见性
简单的理解
两(多)个线程同时针对一个变量进行操作, 一个线程读, 一个线程修改, 此时读到的值不一定是修改过后的值
即读线程没有感知到变量的变化 (其实是 编译器/JVM 对于代码在多线程情况下的优化进行了误判)
从 JMM (Java Memory Model) 角度解释 内存可见性
Java 程序里, 每个线程有自己的工作内存
t1 线程进行读取的时候, 先从主内存读取到工作内存, 再从工作内存中读取值
t2 线程进行修改的值, 先修改自己工作内存中的值, 然后把工作内存的值同步到主内存
由于编译器优化, 导致 t1 没有重新从主内存同步数据到工作内存,读到的结果就是 “修改之前” 的值
这个 “编译器优化”, 就是如果你连续10000次读取值的时候, 如果发现主内存和工作内存中的值没有任何变化, 那么在第10001次读取值的时候, 编译器就不把主内存的数据同步给工作内存了 (同步也是需要消耗资源的…), 而是直接从工作内存读取数据 (编译器默认你第10000次和第10001次的操作是一样的 …)
指令重排序
其实也是编译器优化的误判
比如一段代码中有这样的操作 (List list = new ArrayList<>() ), 可以把将该操作拆分成三个步骤
- 申请内存空间
- 调用构造方法, 将该内存空间初始化成一个合理的对象
- 把内存空间的地址赋值给 list 使用
如果编译器任务按你的代码逻辑 (顺序执行 1->2->3 步)比较慢, 并且修改代码的执行顺序 (从1->2->3 变成 1->3->2) 并不会影响最终的结果, 那么编译器就会将代码的顺序进行调整.
其实这里本质上是 研究 JVM 的大佬对我们这些菜鸟的帮助 (你写的代码如果太差, 我帮你提提速), 但是在多线程情况下, 可能会产生误判 (顺序改变后如果对代码执行结果有影响呐?), 所以说指令重排序是编译器对于代码优化的误判 … (好心办坏事)
volatile
volatile 解决内存可见性和指令重排序的问题
给变量手动加上 volatile 关键字, 就是告诉编译器, 这个变量是 “易变” 的, 每次使用的时候都要重新读取这个变量的内存内容, 不要随随便便进行优化了
问题代码
class Counter {public int count = 0;
}public class Main{public static void main(String[] args) throws InterruptedException {Counter counter = new Counter();Thread t1 = new Thread(() -> {while(counter.count == 0) ;System.out.println("counter.count 已被修改");});Thread t2 = new Thread(() -> {Scanner sc = new Scanner(System.in);System.out.println("请修改 counter.count 的值");counter.count = sc.nextInt();});t1.start();t2.start();t1.join();t2.join();}
}
运行结果
运行之后会发现, 对于 t2 线程中修改 变量 count 的值, 线程 t1 是无感知的, 体现在运行结果上就是死循环一直执行, 程序不会结束
解决方法
给变量 count 加上关键字 volatile
class Counter {volatile public int count = 0;
}
运行结果
运行结果, t1 线程感知到 t2 线程中变量的修改
