【Java并发编程】volatile（三）：内存语义的实现原理

朱雀 2022-12-08 01:33 164阅读 0赞

> 前言：
> 
>  *  [【Java并发编程】volatile（一）：保证多线程下的可见性][Java_volatile]
>  *  [【Java并发编程】volatile（二）：防止指令重排序][Java_volatile 1]

volatile 是 Java 虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用：

*  保证被 volatile 修饰的共享变量对所有线程总数可见的，也就是当一个线程修改了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。
 *  禁止指令重排序优化。

那 volatile 关键字的底层实现是什么呢？答：**内存屏障**。又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执行顺序，二是保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）。

由于编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的新版本。

### 1.volatile 禁止重排序规则 ###

下图是JMM针对编译器制定的volatile重排序规则表：  
![在这里插入图片描述][202104141531184.png_pic_center]  
举例来说，第三行后一个单元格的意思是：在程序中，当第一个操作为普通变量的读或写时，如果第二个操作为volatile写，则编译器不能重排序这两个操作。

从上图可以看出：

*  当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保 volatile 写之前的操作不会被编译器重排序到volatile写之后。 ∙
 *  当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保 volatile 读之后的操作不会被编译器重排序到volatile读之前。 ∙
 *  当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个优布置来小化插入屏障的总数几乎不可能。为此，JMM采取保守策略。下面是基于保守策略的JMM内存屏障插入策略：

*  在每个volatile写操作的前面插入一个StoreStore屏障
 *  在每个volatile写操作的后面插入一个StoreLoad屏障
 *  在每个volatile读操作的后面插入一个LoadLoad屏障
 *  在每个volatile读操作的后面插入一个LoadStore屏障

上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。

### 2.volatile 写时的内存屏障 ###

下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

> 注：对于保证可见性主要就体现在 volatile 写时的两个内存屏障
> 
>  *  StoreStore：保障 volatile 写之前所有的普通写已经刷新到主内存，即该 volatile 写操作的是最新的数据
>  *  StoreLoad：保障修改后的最新数据刷新到内存，并使其余线程工作空间的缓存失效（PS：这里其实是有点总线嗅探的感觉，即其他处理器通过嗅探总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器要对这个数据进行修改操作的时候，会强制重新从系统内存里把数据读到处理器缓存里）

这里比较有意思的是，volatile 写后面的 StoreLoad 屏障。此屏障的作用是避免 volatile写与后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile写的后面是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即return），所以，为了保证能正确实现volatile的内存语义，JMM在采取了保守策略： 在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。

因为volatile写-读内存语义的常见使用模式是：一个写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM 在实现上的一个特点：首先确保正确性，然后再去追求执行效率。

### 3.volatile 读时的内存屏障 ###

下图是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。下面通过具体的示例代码进行说明。

### 4.volatile 读+写时的内存屏障 ###

class VolatileBarrierExample {
               
    	 int a;
    	 volatile int v1 = 1;      
    	 volatile int v2 = 2;       
    	 
    	 void readAndWrite() {
                  
    	   	 int i = v1;　　  // 第一个volatile读 
    	     int j = v2;     // 第二个volatile读      
             a = i + j;      // 普通写
             v1 = i + 1;     // 第一个volatile写
             v2 = j * 2;     // 第二个 volatile写
         }
    }

针对 readAndWrite() 方法，编译器在生成字节码时可以做如下的优化

上面的优化针对任意处理器平台，由于不同的处理器有不同“松紧度”的处理器内存模型，内存屏障的插入还可以根据具体的处理器内存模型继续优化。以X86处理器为例，下图中除最后的StoreLoad屏障外，其他的屏障都会被省略。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]  
前面保守策略下的volatile读和写，在X86处理器平台可以优化成如下图所示。前文提到过，X86处理器仅会对写-读操作做重排序。X86不会对读-读、读-写和写-写操作 做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。在X86中， JMM仅需 在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存 语义。这意味着在 X86处理器中，volatile写的开销比volatile读的开销会大很多（因为执行StoreLoad屏障开销会比较大）。

[Java_volatile]: https://blog.csdn.net/weixin_43935927/article/details/108630814
[Java_volatile 1]: https://blog.csdn.net/weixin_43935927/article/details/115699295
[202104141531184.png_pic_center]: /images/20221123/84957cb7c9094d1fa14c5c62789ad5b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/3ba747c38ddc4497bb4197b6ba3656d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/210433948e2e4ac9a1899b3fc67e2a93.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221123/5adf6e8b08f448dbac2653e16df42f7b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221123/2a4cffeba143488b8558fbe2d2876992.png