前面我们提到内存可见性问题也是引起线程安全的一个原因,本文我们就来详细说一下什么是内存可见性问题。
引入问题
java
import java.util.Scanner;
public class Demo6 {
private static int flag=0;
public static void main(String[] args) {
Thread t1=new Thread(()->{
while (flag==0){
}
System.out.println("t1线程结束");
});
Thread t2=new Thread(()->{
//该线程针对flag进行修改
Scanner scanner=new Scanner(System.in);
System.out.println("请输入flag的值");
flag= scanner.nextInt();
});
t1.start();
t2.start();
}
}

由运行结果可以看出,我们输入了一个非0值,但是t1线程并没有结束,所以这也是一个线程安全问题。
出现这一现象的原因就是内存可见性问题。
这是因为研究JDK的大佬们,希望通过编译器或者JVM对程序员写的代码进行优化。
编译器或者JVM会在我们原有代码逻辑不变的情况下,对我们的代码进行调整,让我们代码的执行效率提高。
但是虽然编译器声称会让原代码的执行逻辑不变,但在多线程中,编译器的判断可能会失误。
这就导致可能因为编译器的优化,让优化后的逻辑和优化前的逻辑在一些细节上会有些偏差 ~
那么这时就会出现一些线程安全问题。
分析问题
在上述循环中,flag==0这一判断在计算机中对应的是一个cmp这样的指令。
而一个cmp指令执行之前又要先进行load (读内存操作)指令。
这里要注意的是load的时间开销可能是cmp的几千倍。
而flag的值的修改是在t2线程中等待用户输入的,由于我们并不确定用户多长时间后才修改flag的值,那么这段时间内,JVM就会误以为没人修改flag的数值,flag的数值始终是0。
那么此时,就把读内存的操作优化为了读寄存器的操作 。
(即把内存中的值读取到寄存器中,后续再进行load操作之后,就不从内存中读取了,直接从寄存器中读取)
那么等到很多秒之后,再修改flag的数值,此时t1线程就感知不到了。
由此可见,编译器优化,使得t1线程的读取操作,不是真正读内存。
调整代码
接下来我们对上述代码的循环内部稍作调整
java
while (flag==0){
try {
Thread.sleep(1);
} catch (InterruptedException e) {
}
}

这次运行结果就是符合我们的预期的,这是什么原因呢?
这是因为当我们加入sleep(1)操作之后就让上面的循环次数大幅度减少了,而且sleep消耗的时间要比load和cmp多得多,那么此时优不优化就无足轻重了。
因此,这次的运行结果是符合我们的预期的。
解决问题
上述问题在编译器优化的角度是难以进行调整的,于是我们在语法中引入了volatile关键字用来解决上述问题(该关键字只能用来修饰变量 )
话不多说,上代码~~~
java
private static volatile int flag=0;
其实很简单,我们只需要在flag前面加上这个关键字即可,此时我们再执行这个代码,运行结果就符合我们的预期了~~~
这是因为 volatile 关键字会强制要求:每次读取该变量时,都必须从内存中重新获取最新值,而不能使用 CPU 寄存器中的数值;每次修改该变量后,也必须立即将新值同步回内存,确保其他线程能 "看到" 最新的变量状态。
结语
通过本文的案例分析,我们不仅搞懂了内存可见性问题的本质 ------ 编译器 / JVM 优化导致线程读取不到变量的最新内存状态,还掌握了最直接的解决方案:用 volatile 关键字修饰变量 。
在实际开发中,当多个线程涉及同一变量的读写操作时,及时使用 volatile,能有效避免因内存可见性引发的线程安全隐患。