Java内存模型与指令重排
Java内存模型与指令重排
本文暂不讲JMM(Java Memory Model)中的主存, 工作内存以及数据如何在其中流转等等, 这些本身还牵扯到硬件内存架构,
直接上手容易绕晕, 先从以下几个点探索JMM
- 原子性
- 有序性
- 可见性
- 指令重排
- CPU指令重排
- 编译器优化重排
- Happen-Before规则
原子性
原子性是指一个操作是不可中断的. 即使是在多个线程一起执行的时候，一个操作一旦开始，就不会被其它线程干扰.
例如CPU中的一些指令, 属于原子性的, 又或者变量直接赋值操作, 也是原子性的, i = 1; 即使有多个线程对i赋值, 相互也不会干扰.
而如i++, 则不是原子性的, 因为他实际上i = i + 1, 若存在多个线程操作i, 结果将不可预期.
有序性
有序性是指在单线程环境中, 程序是按序依次执行的.
而在多线程环境中, 程序的执行可能因为指令重排而出现乱序, 下文会有详细讲述.
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 }
可见性
可见性是指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道这个修改.
会有多种场景影响到可见性:
CPU指令重排
多条汇编指令执行时, 考虑性能因素, 会导致执行乱序, 下文会有详细讲述.
硬件优化（如写吸收，批操作）
cpu2修改了变量T, 而cpu1却从高速缓存cache中读取了之前T的副本, 导致数据不一致.
编译器优化
主要是Java虚拟机层面的可见性, 下文会有详细讲述.
指令重排
指令重排是指在程序执行过程中, 为了性能考虑, 编译器和CPU可能会对指令重新排序.
CPU指令重排
一条汇编指令的执行是可以分为很多步骤的, 分为不同的硬件执行
- 取指 IF
- 译码和取寄存器操作数 ID
- 执行或者有效地址计算 EX (ALU逻辑计算单元)
- 存储器访问 MEM
- 写回 WB (寄存器)
既然指令可以被分解为很多步骤, 那么多条指令就不一定依次序执行.
因为每次只执行一条指令, 依次执行效率太低了, 假设上述每一个步骤都要消耗一个时钟周期,
那么依次执行的话, 一条指令要5个时钟周期, 两条指令要占用10个时钟周期, 三条指令消耗15个时钟.
而如果硬件空闲即可执行下一步, 类似于工厂中的流水线, 一条指令要5个时钟周期,
两条指令只需要6个时钟周期, 因为是错位流水执行, 三条指令消耗7个时钟.
举个例子 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, 因此也需要错位等待.
再来看一个复杂的例子
a = b + c
d = e – f
具体指令执行步骤如图, 不再赘述, 与上图类似, 在执行过程中同样会出现等待.
这边框选的X统称一个气泡, 有没有什么方案可以削减这类气泡呢.
答案自然是可以的, 我们可以在出现气泡之前, 执行其他不相干指令来减少气泡.
例如可以将第五步的加载e到寄存器提前执行, 消除第一个气泡,
同理将第六步的加载f到寄存器提前执行, 消除第二个气泡.
经过指令重排后, 整个流水线会更加顺畅, 无气泡阻塞执行.
原先需要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 }
我们可以通过修改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会产生如图变化.
两者区别在于当jvm运行在-client模式的时候,使用的是一个代号为C1的轻量级编译器,
而-server模式启动的虚拟机采用相对重量级,代号为C2的编译器. C2比C1编译器编译的相对彻底,
会导致程序启动慢, 但服务起来之后, 性能更高, 同时有可能带来可见性问题.
我们将上述代码运行的汇编代码打印出来, 如下图所示, 从红字注释的部分可以看出来,
只有第一次进入循环之前, 检查了下stop的值, 不满足条件, 进入循环后,
再也没有检查stop, 一直在做循环i++.
解决方案也很简单, 只要给stop加上volatile关键字, 再次打印汇编代码, 发现他每次都会检查stop的值.
就不会出现无限循环了.
再来看两个从Java语言规范中摘取的例子, 也是涉及到编译器优化重排, 这里不再做详细解释, 只说下结果.
例子1中有可能出现r2 = 2 并且 r1 = 1;
例子2中是r2, r5值因为都是=r1.x, 编译器会使用向前替换, 把r5指向到r2, 最终可能导致r2=r5=0, r4 = 3;
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()方法.