深刻理解JAVA并发中的有序性问题和解决之道

偏执的太偏执、 2023-09-26 17:41 84阅读 0赞

### 问题 ###

Java并发情况下总是会遇到各种意向不到的问题，比如下面的代码：

int num = 0;
    
    boolean ready = false;
    // 线程1 执行此方法
    public void actor1(I_Result r) {
     if(ready) {
     	r.r1 = num + num;
     } else {
     	r.r1 = 1;
     }
    }
    // 线程2 执行此方法
    public void actor2(I_Result r) { 
     num = 2;
     ready = true; 
    }
    复制代码

*  线程1中如果发现`ready=true`,那么r1的值等于`num + num`，否则等于1，然后将结果保存到`I_Result`对象中
 *  线程2中先修改`num=2`,然后设置`ready=true`

那大家觉得`I_Result`中的`r1值`可能是多少呢？

1.  r1值等于4， 这个大家都能想到, CPU先执行了线程2，然后执行线程1
2.  r1值等于1，这个也容易理解，CPU先执行了线程1，然后执行线程2
3.  那我如果说**r1值有可能等于0**，大家可能觉得离谱，不信的话，我们验证下。

### 压测验证结果 ###

由于并发问题出现的概率比较低，我们可以使用`openjdk`提供的`jcstress`框架进行压测，就能够出现各种可能的情况。

> jcstress：全名The Java Concurrency Stress tests，是一个实验工具和一套测试工具，用于帮助研究JVM、类库和硬件中并发支持的正确性。

1.  **生成压测工程**

mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=com.alvin -DartifactId=juc-order -Dversion=1.0
    复制代码

![daa5ab18d194e7de799cb1363a5b8fdc.png][]

生成的工程代码如下图：

![2b0dc488e9c808b03ba015c32022d27e.png][]

1.  **填充测试内容**

![563e6d0581ead5eae23b2a85647bcd31.png][]

*  方法`actor1`是压测第一个线程干的活，将结果保存到`I_Result`中。
 *  方法`actor2`是压测第二个线程干的活
 *  类前面的`@Outcome`注解用来展示验证结果，特别是`id="0"`这个是我们感兴趣的结果

1.  **运行压测工程**

mvn clean install 
    java -jar target/jcstress.jar
    复制代码

1.  **查看运行结果**

运行结果如下图所示：

![a13993cb17eda6d0de7703e65e342dd7.png][]

*  有4000多次出现了0的结果
 *  大部分情况的结果还是1和4

你是不是还是很困惑，其实这就是并发执行的一些坑，我们下面来解释下原因。

### 原因分析 ###

如果先要出现`r1的值等于0`，那么有一个可能`0+0=0`，那么也就是`num=0`。

你可能想num怎么可能等于0，代码逻辑明明是先设置`num=2`,然后才修改`ready=true`, 最后才会走到`num+num` 的逻辑啊....

在并发的世界里，我们千万不要被固有的思维限制了，那是不是有可能`num=2`和`ready=true`的执行顺序发生了变化呢。如果你想到这里，也基本接近真相了。

**原因：** JAVA中在指令不存在依赖的情况下，会进行顺序的调整，这种现象叫做**指令重排序**，是 JIT 编译器在运行时的一些优化。这也是为什么出现0的根本原因。

> 指令重排不会影响单线程执行的结果，但是在多线程的情况下，会有个可能出现问题。

### 理解指令重排序 ###

前面提到出现问题的原因是因为指令重排序，你可能还是不大理解指令重排序究竟是什么，以及它的作用，那我这边用一个鱼罐头的故事带大家理解下。

我们可以把工人当做CPU，鱼当做指令，工人加工一条鱼需要 50 分钟，如果一条鱼、一条鱼顺序加工，这样是不是比较慢？

![f6604a5e7fd3906eb328a9e757bc2f68.png][]

没办法得优化下，不然要喝西北风了，发现每个鱼罐头的加工流程有 5 个步骤：

*  去鳞清洗 10分钟
 *  蒸煮沥水 10分钟
 *  加注汤料 10分钟
 *  杀菌出锅 10分钟
 *  真空封罐 10分钟

每个步骤中也是用到不同的工具，那能否可以并行呢？如下图所示：

![990dbce5bec7f37e0452ad692defeaa0.png][]

我们发现中间用很多步骤是并行做的，大大的提高了效率。但是在并行加工鱼的过程中，就会出现顺序的调整，比如先做第二条的鱼的某个步骤，然后在做第一条鱼的步骤。

现代 CPU 支持多级指令流水线，几乎所有的冯•诺伊曼型计算机的 CPU，其工作都可以分为 5 个阶段：取指令、指令译码、执行指令、访存取数和结果写回，可以称之为五级指令流水线。CPU 可以在一个时钟周期内，同时运行五条指令的不同阶段（每个线程不同的阶段），本质上流水线技术并不能缩短单条指令的执行时间，但变相地提高了指令地吞吐率。

![aaf4a168875c9a57359ae4d2205355f2.png][]

处理器在进行重排序时，必须要考虑指令之间的数据依赖性

*  单线程环境也存在指令重排，由于存在依赖性，最终执行结果和代码顺序的结果一致
 *  多线程环境中线程交替执行，由于编译器优化重排，会获取其他线程处在不同阶段的指令同时执行

### volatile关键字 ###

那么对于上面的问题，如何解决呢？

**使用volatile关键字。**

![68da024a3806fca6303b5073caa407ad.png][]

`volatile` 的底层实现原理是内存屏障，`Memory Barrier（Memory Fence）`

*  对 `volatile` 变量的写指令后会加入写屏障
 *  对 `volatile` 变量的读指令前会加入读屏障

内存屏障本质上是一个CPU指令，形象点理解就是一个栅栏，拦在那里，无法跨越。

**内存屏障分为写屏障和读屏障，有什么有呢？**

1.  **保证可见性**

*  写屏障保证在该屏障之前的，对共享变量的改动，都同步到主存当中
 *  读屏障保证在该屏障之后，对共享变量的读取，加载的是主存中最新数据

1.  **保证有序性**

*  写屏障会确保指令重排序时，不会将写屏障之前的代码排在写屏障之后
 *  读屏障会确保指令重排序时，不会将读屏障之后的代码排在读屏障之前

![c44241ff130e025366bf79bff3b43604.png][]

回到前面的问题，如果对`ready`加了`volatile`以后，那么num=2就无法到后面去了，同样读取也是，如上图所示。

> final底层也是通过内存屏障实现的，它与volatile一样。
> 
>  *  对final变量的写指令加入写屏障。也就是类初始化的赋值的时候会加上写屏障。
>  *  对final变量的读指令加入读屏障。加载内存中final变量的最新值。

### 总结 ###

JAVA并发中的有序性问题其实比较难理解，本文通过一个例子验证了并发情况下会出现有序性的问题，从而引发意想不到的结果。这个主要的原因是为了提高性能，指令会发生重排序导致的。为了解决这样的问题，我们可以使用`volatile`这个关键字修饰变量，它能够保证有序性和可见性，但是无法保证原子性。如果以后遇到一些成员变量或者静态变量就要特别注意了，需要分析并发情况下会有哪些问题。

[daa5ab18d194e7de799cb1363a5b8fdc.png]: https://img-blog.csdnimg.cn/img_convert/daa5ab18d194e7de799cb1363a5b8fdc.png
[2b0dc488e9c808b03ba015c32022d27e.png]: https://img-blog.csdnimg.cn/img_convert/2b0dc488e9c808b03ba015c32022d27e.png
[563e6d0581ead5eae23b2a85647bcd31.png]: https://img-blog.csdnimg.cn/img_convert/563e6d0581ead5eae23b2a85647bcd31.png
[a13993cb17eda6d0de7703e65e342dd7.png]: https://img-blog.csdnimg.cn/img_convert/a13993cb17eda6d0de7703e65e342dd7.png
[f6604a5e7fd3906eb328a9e757bc2f68.png]: https://img-blog.csdnimg.cn/img_convert/f6604a5e7fd3906eb328a9e757bc2f68.png
[990dbce5bec7f37e0452ad692defeaa0.png]: https://img-blog.csdnimg.cn/img_convert/990dbce5bec7f37e0452ad692defeaa0.png
[aaf4a168875c9a57359ae4d2205355f2.png]: https://img-blog.csdnimg.cn/img_convert/aaf4a168875c9a57359ae4d2205355f2.png
[68da024a3806fca6303b5073caa407ad.png]: https://img-blog.csdnimg.cn/img_convert/68da024a3806fca6303b5073caa407ad.png
[c44241ff130e025366bf79bff3b43604.png]: https://img-blog.csdnimg.cn/img_convert/c44241ff130e025366bf79bff3b43604.png