[转]JVM学习之路(六)——指令重排序

六、指令重排序

根据以往学习多线程的经验,往往就会碰到这样一些例子:明明代码是按照想要的逻辑写的,但是一旦程序执行完后,就出现了一些意想不到的情况,那时只知道是多线程运行的时候出现了问题,具体怎么回事也没搞清楚过。在学习JVM的时候才发现导致这种问题的原因——指令重排序。

一、指令重排序案例重现:

有这样一段程序:

 
  1. int a = 0;
boolean flag = false;
  2.  
  3. //线程1
  4.  
  5. public void writer() {
  6.  
  7. a = 1;
  8.  
  9. flag = true;
  10.  
  11. }
  12.  
  13. //线程2
  14.  
  15. public void reader() {
  16.  
  17. if (flag) {
  18.  
  19. int i= a+1;
  20.  
  21. ...... }
  22.  
  23. }
 

线程1依次执行a=1,flag=true;线程2判断到flag==true后,设置i=a+1。根据代码语义,我们可能会推断此时i的值等于2,因为线程2在判断flag==true时,线程1已经执行了a=1;所以i的值等于a+1=1+1=2;但真实情况却不一定如此,引起这个问题的原因是线程1内部的两条语句a=1;flag=true;可能被重新排序执行,如图:

这就是“指令重排序”问题的案例重现。两个赋值语句尽管他们的代码顺序是一前一后的,但真正执行时却不一定按照代码顺序执行。

那我们就有疑问了,这个指令重排序不会让我们的程序乱套吗?我写的程序都不按我的代码流程走,这还要得?Java、CPU、内存之间的那一套严格的指令重排序规则让我们大可放心,这套规则规定了哪些可以重排,哪些不可以重排。这样,我们的程序就不会乱套了。

二、java程序从编译到执行会经历哪些重排序

1、编译器优化重排序:属于java编译器重排序,会按照JMM(Java内存模型)的规范严格进行,编译器重排序一般不会对程序的正确逻辑造成影响

2、指令级并行重排序:属于CPU重排序,CPU的事情JMM就不好管了,怎么办呢?JMM会要求java编译器在生成指令时加入内存屏障。可以将内存屏障理解为一个密不透风的保护罩,把不能重排序的java指令保护起来,那么处理器在遇到内存屏障保护的指令时就不会对它进行重排序了

3、内存系统重排序:属于CPU重排序,情况与2相似

经过这3个步骤的重排序,一开始编写的.java源代码才有了一个最终可执行的指令序列。

三、单线程中,不会被重排序的逻辑

由于以上3种情况,任意改变任何一个代码的顺序,结果都会大不相同。所以,对于单线程中这样的逻辑代码,是不会被重排序的。


---------------------
作者:zj_daydayup
来源:CSDN
原文:https://blog.csdn.net/u012556994/article/details/81262790?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522158518126519724811817164%2522%252C%2522scm%2522%253A%252220140713.130056874..%2522%257D&request_id=158518126519724811817164&biz_id=0&utm_source=distribute.pc_search_result.none-task
版权声明:本文为作者原创文章,转载请附上博文链接!
 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值