Java内存模型与指令重排

 2019-12-10 15:52  阅读(619)
文章分类:Java Core

本文暂不讲JMM(Java Memory Model)中的主存, 工作内存以及数据如何在其中流转等等,

这些本身还牵扯到硬件内存架构, 直接上手容易绕晕, 先从以下几个点探索JMM

  • 原子性

  • 有序性

  • 可见性

  • 指令重排

    • CPU指令重排
    • 编译器优化重排
  • Happen-Before规则

原子性

原子性是指一个操作是不可中断的. 即使是在多个线程一起执行的时候,

一个操作一旦开始,就不会被其它线程干扰. 例如CPU中的一些指令, 属于原子性的,

又或者变量直接赋值操作(i = 1), 也是原子性的, 即使有多个线程对i赋值, 相互也不会干扰.

而如i++, 则不是原子性的, 因为他实际上i = i + 1, 若存在多个线程操作i, 结果将不可预期.

20191210001376\_1.png

有序性

有序性是指在单线程环境中, 程序是按序依次执行的.

而在多线程环境中, 程序的执行可能因为指令重排而出现乱序, 下文会有详细讲述.

1     class OrderExample {
     2         int a = 0;
     3         boolean flag = false;
     4 
     5         public void writer() {
     6             // 以下两句执行顺序可能会在指令重排等场景下发生变化
     7             a = 1;
     8             flag = true;
     9         }
    10 
    11         public void reader() {
    12             if (flag) {
    13                 int i = a + 1;
    14                 ……
    15             }
    16         }
    17     }

20191210001376\_2.png

可见性

可见性是指当一个线程修改了某一个共享变量的值,其他线程是否能够立即知道这个修改.

会有多种场景影响到可见性:

CPU指令重排

多条汇编指令执行时, 考虑性能因素, 会导致执行乱序, 下文会有详细讲述.

硬件优化(如写吸收,批操作)

cpu2修改了变量T, 而cpu1却从高速缓存cache中读取了之前T的副本, 导致数据不一致.

20191210001376\_3.png

编译器优化

主要是Java虚拟机层面的可见性, 下文会有详细讲述.

指令重排

指令重排是指在程序执行过程中, 为了性能考虑, 编译器和CPU可能会对指令重新排序.

CPU指令重排

一条汇编指令的执行是可以分为很多步骤的, 分为不同的硬件执行

  • 取指 IF
  • 译码和取寄存器操作数 ID
  • 执行或者有效地址计算 EX (ALU逻辑计算单元)
  • 存储器访问 MEM
  • 写回 WB (寄存器)

既然指令可以被分解为很多步骤, 那么多条指令就不一定依次序执行.

因为每次只执行一条指令, 依次执行效率太低了, 假设上述每一个步骤都要消耗一个时钟周期,

那么依次执行的话, 一条指令要5个时钟周期, 两条指令要占用10个时钟周期, 三条指令消耗15个时钟.

20191210001376\_4.png

而如果硬件空闲即可执行下一步, 类似于工厂中的流水线, 一条指令要5个时钟周期,

两条指令只需要6个时钟周期, 因为是错位流水执行, 三条指令消耗7个时钟.

20191210001376\_5.png

举个例子 A = B + C, 需要如下指令

  • 指令1 : 加载B到寄存器R1中
  • 指令2 : 加载C到寄存器R2中
  • 指令3 : 将R1与R2相加, 得到R3
  • 指令4 : 将R3赋值给A

注意下图红色框选部分, 指令1, 2独立执行, 互不干扰.

指令3依赖于指令1, 2加载结果, 因此红色框选部分表示在等待指令1, 2结束.

待指令1, 2都已经走完MEM部分, 数据加载到内存后, 指令3继续执行计算EX.

同理指令4需要等指令3计算完, 才可以拿到R3, 因此也需要错位等待.

20191210001376\_6.png

再来看一个复杂的例子

a = b + c

d = e – f

具体指令执行步骤如图, 不再赘述, 与上图类似, 在执行过程中同样会出现等待.

20191210001376\_7.png

这边框选的X统称一个气泡, 有没有什么方案可以削减这类气泡呢.

答案自然是可以的, 我们可以在出现气泡之前, 执行其他不相干指令来减少气泡.

例如可以将第五步的加载e到寄存器提前执行, 消除第一个气泡,

同理将第六步的加载f到寄存器提前执行, 消除第二个气泡.

20191210001376\_8.png

经过指令重排后, 整个流水线会更加顺畅, 无气泡阻塞执行.

20191210001376\_9.png

原先需要14个时钟周期的指令, 重排后, 只需要12个时钟周期即可执行完毕.

指令重排只可能发生在毫无关系的指令之间, 如果指令之间存在依赖关系, 则不会重排.

如 指令1 : a = 1 指令2: b = a – 1, 则指令1, 2 不会发生重排.

编译器优化

主要指jvm层面的, 如下代码, 在jvm client模式很快就跳出了while循环, 而在server模式下运行, 永远不会停止.

1 /**
     2  * Created by Administrator on 2018/5/3/0003.
     3  */
     4 public class VisibilityTest extends Thread {
     5     private boolean stop;
     6 
     7     public void run() {
     8         int i = 0;
     9         while (!stop) {
    10             i++;
    11        }
    12         System.out.println("finish loop,i=" + i);
    13     }
    14 
    15     public void stopIt() {
    16         stop = true;
    17     }
    18 
    19     public boolean getStop() {
    20          return stop;
    21     }
    22  
    23      public static void main(String[] args) throws Exception {
    24          VisibilityTest v = new VisibilityTest();
    25          v.start();
    26          Thread.sleep(1000);
    27         v.stopIt();
    28          Thread.sleep(2000);
    29          System.out.println("finish main");
    30          System.out.println(v.getStop());
    31     }
    32  }

以32位jdk1.7.0_55为例, 我们可以通过修改JAVA_HOME/jre/lib/i386/jvm.cfg, 将jvm调整为server模式验证下.

修改内容如下图所示, 将-server调整到-client的上面.

-server KNOWN
-client KNOWN
-hotspot ALIASED_TO -client
-classic WARN
-native ERROR
-green ERROR

修改成功后, java -version会产生如图变化.

20191210001376\_10.png

两者区别在于当jvm运行在-client模式的时候,使用的是一个代号为C1的轻量级编译器,

而-server模式启动的虚拟机采用相对重量级,代号为C2的编译器. C2比C1编译器编译的相对彻底,

会导致程序启动慢, 但服务起来之后, 性能更高, 同时有可能带来可见性问题.

我们将上述代码运行的汇编代码打印出来, 打印方法也简单提一下.

给主类运行时加上VM Options, -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly

此时会提示Could not load hsdis-i386.dll; library not loadable; PrintAssembly is disabled

因为打印汇编需要给jdk安装一个插件, 可能需要自己编译hsdis, 不同平台不太一样,

Windows下32位jdk需要的是hsdis-i386.dll, 64位jdk需要hsdis-amd64.dll.

我们把编译好的hsdis-i386.dll放到JAVA_HOME/jre/bin/server以及JAVA_HOME/jre/bin/client目录中.

运行代码, 控制台会把代码对应的汇编指令一起打印出来. 会有很多行, 我们只需要搜索run方法对应的汇编.

搜索 ‘run’ ‘()V’ in ‘VisibilityTest’, 可以找到对应的指令.

如下代码所示, 从红字注释的部分可以看出来,

只有第一次进入循环之前, 检查了下stop的值, 不满足条件进入循环后,

再也没有检查stop, 一直在做循环i++.

1      public void run() {
     2         int i = 0;
     3         while (!stop) {
     4             i++;
     5         }
     6         System.out.println("finish loop,i=" + i);
     7     }
     8   
     9   
    10   # {method} 'run' '()V' in 'VisibilityTest'
    11   ......
    12   0x02d486e9: jne    0x02d48715
    13   // 获取stop的值
    14   0x02d486eb: movzbl 0x64(%ebp),%ecx    ; implicit exception: dispatches to 0x02d48703
    15   0x02d486ef: test   %ecx,%ecx
    16   // 进入while之前, 若stop满足条件, 则跳转到0x02d48703, 不执行while循环
    17   0x02d486f1: jne    0x02d48703         ;*goto
    18                                         ; - VisibilityTest::run@12 (line 10)
    19   // 循环体内, i++
    20   0x02d486f3: inc    %edi               ; OopMap{ebp=Oop off=52}
    21                                         ;*goto
    22                                         ; - VisibilityTest::run@12 (line 10)
    23   0x02d486f4: test   %edi,0xe00000      ;*goto
    24                                         ; - VisibilityTest::run@12 (line 10)
    25                                         ;   {poll}
    26   // jmp, 无条件跳转到0x02d486f3, 一直执行i++操作, 根本不检查stop的值 27   // 导致死循环 28   0x02d486fa: jmp    0x02d486f3
    29   0x02d486fc: mov    $0x0,%ebp
    30   0x02d48701: jmp    0x02d486eb
    31   // 跳出循环
    32   0x02d48703: mov    $0xffffff86,%ecx
    33   ......

解决方案也很简单, 只要给stop加上volatile关键字, 再次打印汇编代码, 发现他每次都会检查stop的值.

就不会出现无限循环了.

1     // 给stop加上volatile后
     2     public void run() {
     3         int i = 0;
     4         while (!stop) {
     5             i++;
     6         }
     7         System.out.println("finish loop,i=" + i);
     8     }
     9 
    10   # {method} 'run' '()V' in 'VisibilityTest'
    11   ......
    12   0x02b4895c: mov    0x4(%ebp),%ecx     ; implicit exception: dispatches to 0x02b4899d
    13   0x02b4895f: cmp    $0x5dd5238,%ecx    ;   {oop('VisibilityTest')}
    14   // 进入while判断
    15   0x02b48965: jne    0x02b4898d         ;*aload_0
    16                                         ; - VisibilityTest::run@2 (line 9)
    17   // 跳转到0x02b48977获取stop
    18   0x02b48967: jmp    0x02b48977
    19   0x02b48969: nopl   0x0(%eax)
       // 循环体内, i++
    20   0x02b48970: inc    %ebx               ; OopMap{ebp=Oop off=49}
    21                                         ;*goto
    22                                         ; - VisibilityTest::run@12 (line 10)
    23   0x02b48971: test   %edi,0xb30000      ;*aload_0
    24                                         ; - VisibilityTest::run@2 (line 9)
    25                                         ;   {poll}
    26   // 循环过程中获取stop的值 27   0x02b48977: movzbl 0x64(%ebp),%eax    ;*getfield stop
    28                                         ; - VisibilityTest::run@3 (line 9)
    29   // 验证stop的值 30   0x02b4897b: test   %eax,%eax
    31   // 若stop不符合条件, 则继续跳转到0x02b48970: inc, 执行i++, 否则中断循环 32   0x02b4897d: je     0x02b48970         ;*ifne
    33                                         ; - VisibilityTest::run@6 (line 9)
    34   0x02b4897f: mov    $0x33,%ecx
    35   0x02b48984: mov    %ebx,%ebp
    36   0x02b48986: nop    
    37   // 跳出循环, 执行System.out.print打印
    38   0x02b48987: call   0x02b2cac0         ; OopMap{off=76}
    39                                         ;*getstatic out
    40                                         ; - VisibilityTest::run@15 (line 12)
    41                                         ;   {runtime_call}
    42   0x02b4898c: int3   
    44   0x02b4898d: mov    $0xffffff9d,%ecx
    45   ......

再来看两个从Java语言规范中摘取的例子, 也是涉及到编译器优化重排, 这里不再做详细解释, 只说下结果.

例子1中有可能出现r2 = 2 并且 r1 = 1;

20191210001376\_11.png

例子2中是r2, r5值因为都是=r1.x, 编译器会使用向前替换, 把r5指向到r2, 最终可能导致r2=r5=0, r4 = 3;

20191210001376\_12.png

Happen-Before先行发生规则

如果光靠sychronized和volatile来保证程序执行过程中的原子性, 有序性, 可见性, 那么代码将会变得异常繁琐.

JMM提供了Happen-Before规则来约束数据之间是否存在竞争, 线程环境是否安全, 具体如下:

顺序原则

一个线程内保证语义的串行性; a = 1; b = a + 1;

volatile规则

volatile变量的写,先发生于读,这保证了volatile变量的可见性,

锁规则

解锁(unlock)必然发生在随后的加锁(lock)前.

传递性

A先于B,B先于C,那么A必然先于C.

线程启动, 中断, 终止

线程的start()方法先于它的每一个动作.

线程的中断(interrupt())先于被中断线程的代码.

线程的所有操作先于线程的终结(Thread.join()).

对象终结

对象的构造函数执行结束先于finalize()方法.

点赞(0)
版权归原创作者所有,任何形式转载请联系作者; Java 技术驿站 >> Java内存模型与指令重排

相关推荐