Volatile是和内存可见性问题是密切相关的。先看下面一段代码,执行结果是什么?
class MyCount{
public int flag = 0;
}
public class ThreadDemo15 {
public static void main(String[] args) {
MyCount myCount = new MyCount();
Thread t1 = new Thread(()->{
while (myCount.flag == 0){
//循环体代码
}
System.out.println("t1 线程循环执行结束");
});
Thread t2 = new Thread(()->{
Scanner sc = new Scanner(System.in);
System.out.println("给flag赋予非0值");
myCount.flag = sc.nextInt();
});
t1.start();
t2.start();
}
}
运行结果如下:
我们的预期是t2把flag改成非О的值之后, t1随之就结束循环了。但是,此时无论怎么给flag赋予非零值,t1线程一直处理循环没有结束,也就是说t1线程拿到的flag是0。
这种情况就是一种内存可见性问题,这段代码实际上是有bug的,涉及到一个线程读一个线程修改,是一个线程不安全问题。下面再来探究一下为什么t1线程总是拿到的是0:
t1线程这里循环体的判断是要分成两个步骤的,先是load,把内存中flag的值读取到寄存器里,然后再是cmp,把寄存器的值和0进行比较,CPU针对寄存器的操作要比内存操作快3-4个数量级,计算机对于内存的操作比硬盘快3-4个数量级。根据比较结果,决定下一步往哪个地方执行。在t2线程真正修改flag值之前,t1线程的循环已经执行了很多次了,而且t1线程load的结果都是一样的。这里会涉及到编译器的优化问题,由于load是在内存中进行加载,执行的速度太慢了(相对于cmp来说),在加上反复load的结果是一样的,JVM就认为不用再重复的load了,认为flag的值没有修改,认为只读一次就好了,这就是编译器的一种优化方式。
一个线程针对一个变量进行读取操作,同时另一个线程针对这个变量进行修改,此时读到的值不一定就是修改后的值,这个读线程没有感知到变量的变化,这就是一种内存可见性问题。此时需要手动干预,可以给flag这个变量加上volatile关键字,这样每一次的读取操作都要重新读取到这个变量的内存内容,就不会进行优化操作了。
class MyCount{
volatile public int flag = 0;
}
下面是来自于Java官方文档的对于内存可见性问题的解释:
从JMM(Java内存模型)的角度重新表述内存可见性问题:
Java程序里,有主内存,每个线程还有自己的工作内存。
t1线程进行读取的时候,只是读取了自己工作内存的值。
t2线程进行修改的时候,先修改的自己工作内存的值,然后再把工作内存的内容同步到主内存中。但是由于编译器优化,导致t1没有重新的从主内存同步数据到自己工作内存,读到的结果就是”修改之前”的结果。
在最开始的代码解释中,我只用了内存和寄存器两种概念,但是其实内存和寄存器之间的存储读取的速度差异实在是太大了,在他们中间还有一种高速缓存器cache,因为不同cup的cache不一样,所以应该是为了避免这种差异,统一叫做工作内存。
总结:volatile是不保证原子性的,原子性是靠synchronized来保证的。但是volatile和synchronized都能保证线程安全。在多线程中,针对同一个变量,一个线程进行读取,一个线程进行修改,那么加上volatile关键字可以保证线程安全问题。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/94533.html