多线程的应用与原理分析3（原子性、可见性、有序性）

曾经终败给现在 2022-03-24 18:08 305阅读 0赞

> **文章最前**： 我是Octopus，这个名字来源于我的中文名--章鱼；我热爱编程、热爱算法、热爱开源。所有源码在我的个人[github][] ；这博客是记录我学习的点点滴滴，如果您对 Python、Java、AI、算法有兴趣，可以关注我的动态，一起学习，共同进步。

**相关文章：**

1.  [多线程的应用与原理分析1][1]
2.  [多线程的应用与原理分析2（线程的状态）][2]
3.  [多线程的应用与原理分析3（原子性、可见性、有序性）][3]
4.  [多线程的应用与原理分析4（synchronized）][4_synchronized]
5.  [多线程的应用与原理分析5（ReentrantLock）][5_ReentrantLock]
6.  [多线程的应用与原理分析6（ReentrantLock）][6_ReentrantLock]
7.  [多线程的应用与原理分析7（Condition）][7_Condition]
8.  [多线程的应用与原理分析8（countdownlatch）][8_countdownlatch]
9.  [多线程的应用与原理分析9（原子操作）][9]
10. [多线程的应用与原理分析10（Semaphore）][10_Semaphore]
11. [多线程的应用与原理分析11（线程池）][11]

--------------------

**JMM怎么解决原子性、可见性、有序性的问题？**

在Java中提供了一系列和并发处理相关的关键字，比如volatile、Synchronized、final、juc等，这些就是Java内存模型封装了底层的实现后提供给开发人员使用的关键字，在开发多线程代码的时候，我们可以直接使用synchronized等关键词来控制并发，使得我们不需要关心底层的编译器优化、缓存一致性的问题了，所以在Java内存模型中，除了定义了一套规范，还提供了开放的指令在底层进行封装后，提供给开发人员使用。  
**原子性保障**  
       在java中提供了两个高级的字节码指令monitorenter和monitorexit，在Java中对应的Synchronized来保证代码块内的操作是原子的;  
**可见性**  
        Java中的volatile关键字提供了一个功能，那就是被其修饰的变量在被修改后可以立即同步到主内存，被其修饰的变量在每次是用之前都从主内存刷新。因此，可以使用volatile来保证多线程操作时变量的可见性。除了volatile，Java中的synchronized和final两个关键字也可以实现可见性；  
**有序性**  
         在Java中，可以使用synchronized和volatile来保证多线程之间操作的有序性。实现方式有所区别：volatile关键字会禁止指令重排。synchronized关键字保证同一时刻只允许一条线程操作。  
**volatile如何保证可见性**  
         volatile变量修饰的共享变量，在进行写操作的时候会多出一个lock前缀的汇编指令，这个指令在前面我们讲解CPU高速缓存的时候提到过，会触发总线锁或者缓存锁，通过缓存一致性协议来解决可见性问题；对于声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，把这个变量所在的缓存行的数据写回到系统内存，再根据我们前面提到过的MESI的缓存一致性协议，来保证多CPU下的各个高速缓存中的数据的一致性。  
**volatile防止指令重排序**  
        指令重排的目的是为了最大化的提高CPU利用率以及性能，CPU的乱序执行优化在单核时代并不影响正确性，但是在多核时代的 多线程能够在不同的核心上实现真正的并行，一旦线程之间共享数据，就可能会出现一些不可预料的问题指令重排序必须要遵循的原则是，不影响代码执行的最终结果，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序，(这里所说的数据依赖性仅仅是针对单个处理器中执行的指令和单个线程中执行的操作.)这个语义，实际上就是as-if-serial语义，不管怎么重排序，单线程程序的执行结果不会改变，编译器、处理器都必须遵守as-if-serial语义；  
**多核心多线程下的指令重排影响**

package lock;
    
    /**
     * @author zhangyu
     * @version V1.0
     * @ClassName: TestThread
     * @Description: TOTO
     * @date 2019/1/22 16:12
     **/
    
    
    public class TestThread {
        private static int x = 0, y = 0;
        private static int a = 0, b = 0;
    
        public static void main(String[] args) throws InterruptedException {
            Thread t1 = new Thread(() -> {
                a = 1;
                x = b;
            });
    
            Thread t2 = new Thread(() -> {
                b = 1;
                y = a;
            });
    
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println("x=" + x + "->y=" + y);
        }
    }

如果不考虑编译器重排序和缓存可见性问题，上面这段代码可能会出现的结果是 x=0,y=1; x=1,y=0; x=1,y=1这三种结果，因为可能是先后执行t1/t2，也可能是反过来，还可能是t1/t2交替执行，但是这段代码的执行结果也有可能是x=0,y=0。这就是在乱序执行的情况下会导致的一种结果，因为线程t1内部的两行代码之间不存在数据依赖，因此可以把x=b乱序到a=1之前；同时线程t2中的y=a也可以早于t1中的a=1执行，那么他们的执行顺序可能是：  
l t1: x=b  
l t2:b=1  
l t2:y=a  
l t1:a=1  
       所以从上面的例子来看，重排序会导致可见性问题。但是重排序带来的问题的严重性远远大于可见性，因为并不是所有指令都是简单的读或写，比如DCL的部分初始化问题。所以单纯的解决可见性问题还不够，还需要解决处理器重排序问题；  
**内存屏障**  
      内存屏障需要解决我们前面提到的两个问题，一个是编译器的优化乱序和CPU的执行乱序，我们可以分别使用优化屏障和内存屏障这两个机制来解决  
**从CPU层面来了解一下什么是内存屏障**  
       CPU的乱序执行，本质还是，由于在多CPU的机器上，每个CPU都存在cache，当一个特定数据第一次被特定一个CPU获取时，由于在该CPU缓存中不存在，就会从内存中去获取，被加载到CPU高速缓存中后就能从缓存中快速访问。当某个CPU进行写操作时，它必须确保其他的CPU已经将这个数据从他们的缓存中移除，这样才能让其他CPU安全的修改数据。显然，存在多个cache时，我们必须通过一个cache一致性协议来避免数据不一致的问题，而这个通讯的过程就可能导致乱序访问的问题，也就是运行时的内存乱序访问。  
     现在的CPU架构都提供了内存屏障功能，在x86的cpu中，实现了相应的内存屏障写屏障(store barrier)、读屏障(load barrier)和全屏障(Full Barrier)，主要的作用是：  
     Ø 防止指令之间的重排序  
     Ø 保证数据的可见性

**store barrier**  
        store barrier称为写屏障，相当于storestore barrier, 强制所有在storestore内存屏障之前的所有执行，都要在该内存屏障之前执行，并发送缓存失效的信号。所有在storestore barrier指令之后的store指令，都必须在storestore barrier屏障之前的指令执行完后再被执行。也就是进制了写屏障前后的指令进行重排序，是的所有store barrier之前发生的内存更新都是可见的（这里的可见指的是修改值可见以及操作结果可见）  
  
**                                                              **![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70][]  
**load barrier**  
       load barrier称为读屏障，相当于loadload barrier，强制所有在load barrier读屏障之后的load指令，都在load barrier屏障之后执行。也就是进制对load barrier读屏障前后的load指令进行重排序， 配合store barrier，使得所有store barrier之前发生的内存更新，对load barrier之后的load操作是可见的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70 1][]

**Full barrier**  
         full barrier成为全屏障，相当于storeload，是一个全能型的屏障，因为它同时具备前面两种屏障的效果。强制了所有在storeload barrier之前的store/load指令，都在该屏障之前被执行，所有在该屏障之后的的store/load指令，都在该屏障之后被执行。禁止对storeload屏障前后的指令进行重排序。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70 2][]

总结：内存屏障只是解决顺序一致性问题，不解决缓存一致性问题，缓存一致性是由cpu的缓存锁以及MESI协议来完成的。而缓存一致性协议只关心缓存一致性，不关心顺序一致性。所以这是两个问题编译器层面如何解决指令重排序问题  
        在编译器层面，通过volatile关键字，取消编译器层面的缓存和重排序。保证编译程序时在优化屏障之前的指令不  
会在优化屏障之后执行。这就保证了编译时期的优化不会影响到实际代码逻辑顺序。

**volatile为什么不能保证原子性**  
        我们通过下面一个例子，对一个通过volatile修饰的值进行递增：

public class Demo {
       volatile int i;
       public void incr(){
          i++;
       } 
       public static void main(String[] args) {
        new Demo().incr();
       }
    }

然后通过javap -c Demo.class，去查看字节码，对一个原子递增的操作，会分为三个步骤：

1.读取volatile变量的值到local；

2.增加变量的值；

3.把local的值写回让其他线程可见；

[github]: https://github.com/zhangyu345293721
[1]: https://blog.csdn.net/zy345293721/article/details/86565631
[2]: https://blog.csdn.net/zy345293721/article/details/86583663
[3]: https://blog.csdn.net/zy345293721/article/details/86596268
[4_synchronized]: https://blog.csdn.net/zy345293721/article/details/86607632
[5_ReentrantLock]: https://blog.csdn.net/zy345293721/article/details/86617801
[6_ReentrantLock]: https://blog.csdn.net/zy345293721/article/details/86621392
[7_Condition]: https://blog.csdn.net/zy345293721/article/details/86622891
[8_countdownlatch]: https://blog.csdn.net/zy345293721/article/details/86636846
[9]: https://blog.csdn.net/zy345293721/article/details/86645245
[10_Semaphore]: https://blog.csdn.net/zy345293721/article/details/86644996
[11]: https://blog.csdn.net/zy345293721/article/details/86646019
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70]: /images/20220323/464cebe10e3f4cdab58b0dd125a7416b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70 1]: /images/20220323/20b4d20f1b89405196107aa1ee850aa1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5MzQ1MjkzNzIx_size_16_color_FFFFFF_t_70 2]: /images/20220323/4567552369bb466eb09cd5a4f799843c.png