volatile的内存语义

野性酷女 2022-11-24 12:57 195阅读 0赞

## 前言 ##

*  当**声明共享变量为volatile后**，对这个变量的读/写将会很特别。为了揭开volatile的神秘面  
    纱，下面**将介绍volatile的内存语义及volatile内存语义的实现**。

volatile的应用与底层原理详见：[《volatile的应用与底层原理》][volatile]

## volatile的特性 ##

*  理解volatile特性的一个好方法是把对volatile变量的单个读/写，看成是使用同一个锁对这些单个读/写操作做了同步。下面通过具体的示例来说明，示例代码如下。

class VolatileFeaturesExample { 
        volatile long vl = 0L; // 使用volatile声明64位的long型变量
        public void set(long l) { 
            vl = l; // 单个volatile变量的写
        }
        public void getAndIncrement () { 
            vl++; // 复合（多个）volatile变量的读/写
        } 
        public long get() { 
            return vl; // 单个volatile变量的读
        }
    }

> 假设有多个线程分别调用上面程序的3个方法，这个程序在语义上和下面程序等价。

class VolatileFeaturesExample2 { 
        long vl = 0L; // 64位的long型普通变量
        public synchronized void set(long l) {  // 对单个的普通变量的写用同一个锁同步
            vl = l;
        }
        public void getAndIncrement () {  // 普通方法调用
            long temp = get(); // 调用已同步的读方法
            temp += 1L; // 普通写操作
            set(temp); // 调用已同步的写方法
        }
        public synchronized long get() {  // 对单个的普通变量的读用同一个锁同步
            return vl;
        }
    }

如上面示例程序所示，**一个volatile变量的单个读/写操作**，**与一个普通变量的读/写操作都是使用同一个锁来同步**，它们之间的**执行效果相同**。

*  **锁的happens-before规则** **保证释放锁和获取锁** **的两个线程之间的内存可见性**，
 *  这意味着对**一个volatile变量的读**，**总是能看到（任意线程）对这个volatile变量最后的写入**。

**总结**：

*  **锁的语义决定了临界区代码的执行具有原子性**。这意味着，即使是64位的long型和double  
    型变量，只要它是volatile变量，对该变量的读/写就具有原子性。
 *  如果是多个volatile 操作或**类似于 volatile++ 这种复合操作，这些操作整体上不具有原子性**。
 *  我理解为：锁适用于多线程，volatite适用于单线程。  
    **简而言之，volatile变量自身具有下列特性。**
    
     *  可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
    
     *  原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

## volatile写-读建立的happens-before关系 ##

*  从JSR-133开始（即从JDK5开始），volatile变量的写-读可以实现线程之间的通信。
 *  从内存语义的角度来说， volatile的写-读与锁的释放-获取有相同的内存效果：
    
     *  volatile写和锁的释放有相同的内存语义；
     *  volatile读与锁的获取有相同的内存语义。

class VolatileExample { 
        int a = 0;
        volatile boolean flag = false;
        public void writer() { 
            a = 1; // 1
            flag = true; // 2
        } 
        public void reader() { 
            if (flag) {  // 3
                int i = a; // 4
    
            }
        }
    }

*  假设线程A执行writer()方法之后，线程B执行reader()方法。根据happens-before规则，这个  
    过程建立的happens-before关系可以分为3类：  
    1）根据程序次序规则，1 happens-before 2; 3 happens-before 4。  
    2）根据volatile规则，2 happens-before 3。  
    3）根据happens-before的传递性规则，1 happens-before 4。  
    上述happens-before关系的图形化表现形式如下  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70]
 *  在上图中，每一个箭头链接的两个节点，代表了一个happens-before关系。**黑色箭头**表示程  
    序顺序规则；**橙色箭头**表示volatile规则；**蓝色箭头**表示组合这些规则后提供的happens-before保  
    证。
 *  这里**A线程写一个volatile变量后**，**B线程读同一个volatile变量**。**A线程在写volatile变量之  
    前所有可见的共享变量，在B线程读同一个volatile变量后，将立即变得对B线程可见**

## volatile写-读的内存语义 ##

**volatile写的内存语义如下：**

*  当写一个volatile变量时，\*\*JMM会把该线程对应的 本地内存 中的共享变量值刷新到 主内存 \*\*。
 *  以上面示例程序VolatileExample为例，假设线程A首先执行writer()方法，随后线程B执行reader()方法，初始时两个线程的本地内存中的flag和a都是初始状态。图3-17是线程A执行volatile写后，共享变量的状态示意图  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 1]  
    **volatile读的内存语义如下。**
    
     *  当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效。线程接下来将从主  
        内存中读取共享变量。
     *  下图为线程B读同一个volatile变量后，共享变量的状态示意图。
     *  ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 2]  
        **下面对volatile写和volatile读的内存语义做个总结**。
        
         *  线程A **写一个volatile变量**，**实质上**是线程A向接下来将要读这个volatile变量的某个线程  
            发出了（其对共享变量所做修改的）消息。
         *  线程B **读一个volatile变量**，**实质上**是线程B接收了之前某个线程发出的（在写这个volatile  
            变量之前对共享变量所做修改的）消息。
         *  **线程A写**一个volatile变量，**随后线程B读**这个volatile变量，这个过程**实质上是线程A通过  
            主内存向线程B发送消息**。

## volatile内存语义的实现 ##

**下面来看看JMM如何实现volatile写/读的内存语义。**  
为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。下表是**JMM针对 编译器** 制定的**volatile重排序规则表**  
![在这里插入图片描述][20200806113105163.png]  
**从表中我们可以总结出:**

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

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

*  在每个volatile **写操作的前面** 插入一个StoreStore屏障。
 *  在每个volatile **写操作的后面** 插入一个StoreLoad屏障。
 *  在每个volatile **读操作的后面** 插入一个LoadLoad屏障。
 *  在每个volatile **读操作的后面** 插入一个LoadStore屏障。
 *  (没错，**读都是在后面**，不用怀疑自己的眼睛。)

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

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

*  **StoreStore屏障**可以保证在volatile写之前，其前面的所有普通写操作已经对任  
    意处理器可见了。这是因为StoreStore屏障**将保障上面所有的普通写在volatile写之前刷新到主内存**。
 *  **StoreLoad屏障**的作用是**避免volatile写与后面可能有的volatile读/写操作重排序**。
 *  因为编译器常常无法准确判断在一个volatile写的后面是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即return）。
 *  为了保证能正确实现volatile的内存语义，**JMM在采取了保守策略：在每个volatile写的后面，或者在每个volatile读的前面插入一个StoreLoad屏障**。
 *  从整体执行效率的角度考虑，JMM最终选择了在每个volatile写的后面插入一个StoreLoad屏障。
 *  因为**volatile写-读内存语义的常见使用模式**是：\*\*一个写线程写volatile变量，多个读线程读同一个volatile变量。\*\*当读线程的数量大大超过写线程时，选择在volatile写之后插StoreLoad屏障将带来可观的执行效率的提升。（但并没有选择这种）从这里可以看到JMM在实现上的一个特点：**首先确保正确性，然后再去追求执行效率**。

**下面是在保守策略下，volatile读插入内存屏障后生成的指令序列示意图**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 4]

*  **LoadLoad屏障**用来**禁止**处理器把上面的volatile读**与下面的普通读重排序**。
 *  **LoadStore屏障**用来**禁止**处理器把上面的volatile读**与下面的普通写重排序** 。

**上述volatile写和volatile读的内存屏障插入策略非常保守。**  
在实际执行时，只要不改变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()方法，编译器在生成字节码时可以做如下的优化。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 5]  
**最后的StoreLoad屏障不能省略**。因为第二个volatile写之后，方法立即return。此时编  
译器可能无法准确断定后面是否会有volatile读或写，为了安全起见，编译器通常会在这里插  
入一个StoreLoad屏障。

内存屏障的插入还可以根据具体的处理器内存模型继续优化。以X86处理器为例，下图中除最后的StoreLoad屏障外，其他的屏障都会被省略。

*  因为X86处理器仅会对写-读操作做重排序。X86不会对**读-读**、**读-写**和**写-写**操作  
    做重排序，因此在X86处理器中会省略掉这3种操作类型对应的内存屏障。

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

*  这意味着在X86处理器中，**volatile写的开销比volatile读的开销会大很多**（因为执行StoreLoad屏障开销会比较大）。

## JSR-133为什么要增强volatile的内存语义 ##

*  在JSR-133之前的旧Java内存模型中，虽然不允许volatile变量之间重排序，但旧的Java内存模型允许volatile变量与普通变量重排序，在旧的内存模型中，VolatileExample示例程序**可能被重排序成下列时序来执行**，如图所示。

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

*  在旧的内存模型中，当1和2之间没有数据依赖关系时，1和2之间就可能被重排序（3和4类似）。其结果就是：读线程B执行4时，不一定能看到写线程A在执行1时对共享变量的修改。
 *  因此， **在旧的内存模型中，volatile的写-读没有锁的释放-获取所具有的内存语义**。  
    **为了提供一种比锁更轻量级的线程之间通信的机制，**
 *  JSR-133专家组决定增强volatile的内存语义：严格限制编译器和处理器对volatile变量与普通变量的重排序，**确保volatile的写-读和锁的释放-获取具有相同的内存语义**。
 *  从编译器重排序规则和处理器**内存屏障插入策略来看**，**只要volatile变量与普通变量之间的重排序可能会破坏volatile的内存语义**，**这种重排序就会被编译器重排序规则和处理器内存屏障插入策略禁止**。

[volatile]: https://blog.csdn.net/fristjcjdncg/article/details/107805805
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70]: /images/20221124/f7b0dc3944244123a3de85a7b846e6f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 1]: /images/20221124/22d143847aab4652bacbbe3f8860670e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 2]: /images/20221124/fef31f48d751416db191b393b658f438.png
[20200806113105163.png]: /images/20221124/4f7e6e1231cc4c9da24c10c632d9dc73.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 3]: /images/20221124/dfc6346087d1444dadcb3b2b1cdf7f4c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 4]: /images/20221124/9744aed374444be992b1ea8eab3d2adc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 5]: /images/20221124/7302621d16c54777938c1bacac03bc76.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 6]: /images/20221124/d8dc531c2c0b45e78c49e4e54c63705c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZyaXN0amNqZG5jZw_size_16_color_FFFFFF_t_70 7]: /images/20221124/60ee576d1a0b49cbbff569b1f55e392d.png