码迷,mamicode.com
首页 > 编程语言 > 详细

内存可见性,指令重排序,JIT。。。。。。从一个知乎问题谈起

时间:2017-12-04 20:38:42      阅读:219      评论:0      收藏:0      [点我收藏+]

标签:自增   场景   总结   lock   jvm   编译   nbsp   window   无法   

在知乎上看到一个问题《java中volatile关键字的疑惑?》,引起了我的兴趣

 

问题是这样的:

 1 package com.cc.test.volatileTest;
 2 
 3 public class VolatileBarrierExample {
 4     private static boolean stop = false;
 5 
 6     public static void main(String[] args) throws InterruptedException {
 7         Thread thread = new Thread(new Runnable() {
 8             @Override
 9             public void run() {
10                 while (!stop) {
11                 }
12             }
13         });
14 
15         thread.start();
16         Thread.sleep(1000);
17         stop = true;
18         thread.join();
19     }
20 }

 

这段代码的主要目的是:主线程修改非volatile类型的全局变量stop,子线程轮询stop,如果stop发生变动,则程序退出。

但是如果实际运行这段代码会造成死循环,程序无法正常退出。

我们当然知道由于stop变量不是volatile的,主线程对stop的修改不一定能被子线程看到而引起的。

 

但是题主玩了个花样,额外定义了一个static类型的volatile变量i,在while循环中对i进行自增操作,代码如下所示:

 1 package com.cc.test.volatileTest;
 2 
 3 public class VolatileBarrierExample {
 4     private static boolean stop = false;
 5     private static volatile int i = 0;
 6 
 7     public static void main(String[] args) throws InterruptedException {
 8         Thread thread = new Thread(new Runnable() {
 9             @Override
10             public void run() {
11                 int i = 0;
12                 while (!stop) {
13                     i++;
14                 }
15             }
16         });
17 
18         thread.start();
19         Thread.sleep(1000);
20         stop = true;
21         thread.join();
22     }
23 }

 

这段程序是可以在运行一秒后结束的,也就是说子线程对volatile类型变量i的读写,影响了非volatile类型变量stop的可见性!

 

 

看起来令人感到困惑,但是实际上这个问题是不成立的。

先给出概括性的答案:stop变量的可见性无论在哪种场景中都没有得到保证。这两个场景中程序是否能正常退出,跟JVM实现与CPU架构有关,没有确定性的答案。

 

下面从两个不同的角度来分析

一:happens-before原则:

第一个场景就不谈了,即使在第二种场景里,虽然子线程中有对volatile类型变量i的读写+非volatile类型变量stop的读,但是主线程中只有对非volatile类型变量stop的写入,因此无法建立 (主线程对stop的写) happens-before于 (子线程对stop的读) 的关系

也就是不能指望主线程对stop的写一定能被子线程看到。

虽然场景二在实际运行时程序依然正确终止了,但是这个只能算是运气好,如果换一种JVM实现或者换一种CPU架构,可能场景二也会陷入死循环。

可以设想这样的一个场景,主/子线程分别在core1/core2上运行,core1的cache中有stop的副本,core2的cache中有stop与i的副本,而且stop和i不在同一条cacheline里。

core1修改了stop变量,但是由于stop不是volatile的,这个改动可以只发生在core1的cache里,而被修改的cacheline理论上可以永远不刷回内存,这样core2上的子线程就永远也看不到stop的变化了。

二:JIT角度:

由于run方法里的while循环会被执行很多次,所以必然会触发jit编译,下面来分析两种情况下jit编译后的结果(触发了多次jit编译,只贴出最后一次C2等级jit编译后的结果)

如何查看JIT后的汇编码请参看我的这篇博文:《如何在windows平台下使用hsdis与jitwatch查看JIT后的汇编码》

A. i为run方法内的局部变量的情况:

技术分享图片

 

    1. 在第一个红框处检测stop变量,如果为true,那么跳转到L0001处继续执行(L0001处再往下走函数就退出了),但此时stop为false,所以不会走这个分支
    2. L0000,inc %ebp。也就是i++
    3. test %eax, -0x239864a(%rip),轮询SAFEPOINT的操作,可以无视
    4. jmp L0000,无条件跳转回L0000处继续执行i++

 

如果把jit编译后的代码改写回来,大概是这个样子

1 if(!stop){
2      while(true){
3           i++;
4     }
5 }

 

非常明确的指令重排序,JVM觉得每次循环都去访问非volatile类型的stop变量太浪费了,就只在函数执行之初访问一次stop,后续无论stop变量怎么变,都不管了。

第一种情况死循环就是这么来的。

 

B. i为全局的volatile变量的情况:

 技术分享图片

 

从第一个红框开始看:

    1. jmp L0001,无条件跳转到label L0001处
    2. movzbl 0x6c(%r10),%r8d; 访问static变量stop,并将其复制到寄存器r8d里
    3. test %r8d, %r8d; je L0000; 如果r8d里的值为0,跳转到L0000处,否则继续往下走(函数结束)
    4. L000: mov 0x68(%r10), %r8d; 访问static变量i,并将其复制到寄存器r8d里
    5. inc %r8d; 自增r8d里的值
    6. mov %r8d, 0x68(%r10); 将自增后r8d里的新值复制回static变量i中(上面三行是i++的流程)
    7. lock addl $0x0, (%rsp); 给rsp寄存器里的值加0,没有任何效果,关键在于前面的lock前缀,会导致cache line的刷新,从而实现变量i的volatile语义
    8. test %eax, -0x242a056(%rip); 轮询SAFEPOINT的操作,可以无视
    9. L0001,回到step 2

也就是说,每次循环都会去访问一次stop变量,迟早会访问到stop被修改后的新值(但是不能确保),导致循环结束。

 

 这两种场景的区别主要在于第二种情况的循环中有对static volatile类型变量i的访问,导致jit编译时JVM无法做出激进的优化,是附加的效果。

 

 

总结

涉及到内存可见性的问题,一定要用happens-before原则细致分析。因为你很难知道JVM在背后悄悄做了什么奇怪的优化。

 

内存可见性,指令重排序,JIT。。。。。。从一个知乎问题谈起

标签:自增   场景   总结   lock   jvm   编译   nbsp   window   无法   

原文地址:http://www.cnblogs.com/stevenczp/p/7978554.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!