volatile关键字详解

我会带着你远行 2022-05-23 00:19 213阅读 0赞

对于synchronized关键字相信大家都已经不陌生了，synchronized的性能一直以来被各种吐槽（当然java团队一直没有放弃synchronized,一直在为性能的提升努力着，在JDK1.8中CurrentHashMap放弃了ReentrantLock而使用synchronized，可见synchronized性能应该是提升不少的）。而volatile关键字可以说是Java虚拟机提供的最轻量级的同步机制（当然它并不能替代synchronized，后面会有讲解）。  
在了解volatile关键字前，需要对Java内存模型有一定的了解，可以参考：[Java内存模型详解][Java]

#### volatile的两大特性 ####

**特性一：保证此变量对所有线程的可见性**。可见性的保证是基于CPU的内存屏障指令，被JSP-133抽象为happens-before原则。这里的“可见性”是指当一条线程修改了这个变量的值，新的值会立刻同步到主内存当中。而其他线程读取这个变量的时候，也会从主内存中拉取最新的变量值。而普通变量不能做到这一点，普通变量的值在线程间传递均需要通过主内存来完成，例如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再从主内存进行读取操作，新变量值才会对线程B可见。（注意误区：不是说只有等线程A操作完之后才，线程B才可以读取变量值，只是说新变量要等A操作完后才可以被B读取）。

举个例子：  
对于一个普通静态变量  
static int s = 0；  
线程A执行如下代码：  
s = 3；  
![这里写图片描述][70]  
![这里写图片描述][70 1]  
![这里写图片描述][70 2]  
![这里写图片描述][70 3]  
通过一系列的内存读写操作，线程A把静态变量 s=0 从主内存读到工作内存，再把 s=3 的更新结果同步到主内存当中。从单线程的角度来看，这个过程没有任何问题。  
这时候我们引入线程B，执行如下代码：  
System.out.println(“s=” + s);  
那么输出的结果会是什么呢？答案是3或者0。对于3很好理解，线程A在赋值完后内存中的s值为3，所以线程B读取的也是3，但为什么会出现0呢？假如在线程A赋值s=3给主内存时，线程B读取到主内存中的值就是0。  
![这里写图片描述][70 4]  
![这里写图片描述][70 5]  
![这里写图片描述][70 6]  
![这里写图片描述][70 7]  
这时我们就可以使用volatile关键字来解决，这得益于java语言的先行发生原则（happens-before），在计算机科学中，先行发生原则是两个事件的结果之间的关系，如果一个事件发生在另一个事件之前，结果必须反映，即使这些事件实际上是乱序执行的（通常是优化程序流程）。  
这里所谓的事件，实际上就是各种指令操作，比如读操作、写操作、初始化操作、锁操作等等。

先行发生原则作用于很多场景下，包括同步锁、线程启动、线程终止、volatile。我们这里只列举出volatile相关的规则：

对于一个volatile变量的写操作先行发生于后面对这个变量的读操作。

回到上述的代码例子，如果在静态变量s之前加上volatile修饰符：

volatile static int s = 0；

线程A执行如下代码：  
s = 3；

这时候我们引入线程B，执行如下代码：  
System.out.println(“s=” + s);

当线程A先执行的时候，把s = 3写入主内存的事件必定会先于读取s的事件。所以线程B的输出一定是s = 3。  
到这里可能会有一个误区，既然volatile变量对其他线程是可见的，是不是说volatile变量的运算在并发下是安全的呢？上篇文章中我们提到Java内存模型的三种特性：原子性、可见性、有序性。而volatile并不保证原子性。如下：

public class VolatileVisibility {
        public static volatile int i =0;
    
        public static void increase(){
            i++;
        }
    }

正如上述代码所示，i变量的任何改变都会立马反应到其他线程中，但是如此存在多条线程同时调用increase()方法的话，就会出现线程安全问题，毕竟i++;操作并不具备原子性，该操作是先读取值，然后写回一个新值，相当于原来的值加上1，分两步完成，如果第二个线程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败，因此对于increase方法必须使用synchronized修饰，以便保证线程安全，需要注意的是一旦使用synchronized修饰方法后，由于synchronized本身也具备与volatile相同的特性，即可见性，因此在这样种情况下就完全可以省去volatile修饰变量。

public class VolatileVisibility {
        public static int i =0;
    
        public synchronized static void increase(){
            i++;
        }
    }

因此，什么时候适合用volatile呢？

1.运行结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

2.变量不需要与其他的状态变量共同参与不变约束。

第一条很好理解，就是上面的代码例子。第二条是什么意思呢？可以看看下面这个场景：

volatile static int start = 3;  
volatile static int end = 6;

线程A执行如下代码：  
while (start < end)\{  
//do something  
\}

线程B执行如下代码：  
start+=3;  
end+=3;

这种情况下，一旦在线程A的循环中执行了线程B，start有可能先更新成6，造成了一瞬间 start == end，从而跳出while循环的可能性。  
**特性二：禁止指令重排序优化。**阻止编译时和运行时的指令重排。编译时JVM编译器遵循内存屏障的约束，运行时依靠CPU屏障指令来阻止重排。普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是Java内存模型中描述的所谓的“线程内表现为串行的语义”。

#### 什么是指令重排？ ####

指令重排是指JVM在编译Java代码的时候，或者CPU在执行JVM字节码的时候，对现有的指令顺序进行重新排序。

指令重排的目的是为了在不改变程序执行结果的前提下，优化程序的运行效率。需要注意的是，这里所说的不改变执行结果，指的是不改变单线程下的程序执行结果。

然而，指令重排是一把双刃剑，虽然优化了程序的执行效率，但是在某些情况下，会影响到多线程的执行结果。我们来看看下面的例子：

boolean contextReady = false;

在线程A中执行:  
context = loadContext();  
contextReady = true;

在线程B中执行:  
while( ! contextReady )\{  
sleep(200);  
\}  
doAfterContextReady (context);

以上程序看似没有问题。线程B循环等待上下文context的加载，一旦context加载完成，contextReady == true的时候，才执行doAfterContextReady 方法。

但是，如果线程A执行的代码发生了指令重排，初始化和contextReady的赋值交换了顺序：

boolean contextReady = false;

在线程A中执行:  
contextReady = true;  
context = loadContext();

在线程B中执行:  
while( ! contextReady )\{  
sleep(200);  
\}  
doAfterContextReady (context);

这个时候，很可能context对象还没有加载完成，变量contextReady 已经为true，线程B直接跳出了循环等待，开始执行doAfterContextReady 方法，结果自然会出现错误。

需要注意的是，这里java代码的重排只是为了简单示意，真正的指令重排是在字节码指令的层面。如果我们在某些情况下想阻止指令重排序该怎么办呢？可以是用内存屏障。

#### 什么是内存屏障？ ####

内存屏障（Memory Barrier）是一种CPU指令，维基百科给出了如下定义：

A memory barrier, also known as a membar, memory fence or fence instruction, is a type of barrier instruction that causes a CPU or compiler to enforce an ordering constraint on memory operations issued before and after the barrier instruction. This typically means that operations issued prior to the barrier are guaranteed to be performed before operations issued after the barrier.

翻译结果如下：

内存屏障也称为内存栅栏或栅栏指令，是一种屏障指令，它使CPU或编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。 这通常意味着在屏障之前发布的操作被保证在屏障之后发布的操作之前执行。

内存屏障共分为四种类型：

LoadLoad屏障：  
抽象场景：Load1; LoadLoad; Load2  
Load1 和 Load2 代表两条读取指令。在Load2要读取的数据被访问前，保证Load1要读取的数据被读取完毕。

StoreStore屏障：  
抽象场景：Store1; StoreStore; Store2  
Store1 和 Store2代表两条写入指令。在Store2写入执行前，保证Store1的写入操作对其它处理器可见

LoadStore屏障：  
抽象场景：Load1; LoadStore; Store2  
在Store2被写入前，保证Load1要读取的数据被读取完毕。

StoreLoad屏障：  
抽象场景：Store1; StoreLoad; Load2  
在Load2读取操作执行前，保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是四种屏障中最大的。

在一个变量被volatile修饰后，JVM会为我们做两件事：

1.在每个volatile写操作前插入StoreStore屏障，在写操作后插入StoreLoad屏障。  
2.在每个volatile读操作前插入LoadLoad屏障，在读操作后插入LoadStore屏障。

或许这样说有些抽象，我们看一看刚才线程A代码的例子：

boolean contextReady = false;

在线程A中执行:  
context = loadContext();  
contextReady = true;

我们给contextReady 增加volatile修饰符，会带来什么效果呢？

![这里写图片描述][70 8]

由于加入了StoreStore屏障，屏障上方的普通写入语句 context = loadContext() 和屏障下方的volatile写入语句 contextReady = true 无法交换顺序，从而成功阻止了指令重排序。

![这里写图片描述][70 9]

前面提到的happens-before是JSR-133规范之一，内存屏障是CPU指令。可以简单认为前者是最终目的，后者是实现手段。

参考资料：《程序员小灰公众号》  
[https://blog.csdn.net/javazejian/article/details/72772461\#volatile%E5%86%85%E5%AD%98%E8%AF%AD%E4%B9%89][https_blog.csdn.net_javazejian_article_details_72772461_volatile_E5_86_85_E5_AD_98_E8_AF_AD_E4_B9_89]  
《深入理解Java虚拟机》

[Java]: https://blog.csdn.net/weixin_40096176/article/details/80497137
[70]: /images/20220523/12852d32db954523b9fb53a6c7506896.png
[70 1]: /images/20220523/916a3ffe94fd482ca4341db3518c92d3.png
[70 2]: /images/20220523/0a1cb48561d3452a9101f4bea316277b.png
[70 3]: /images/20220523/5c368acdb28b4fa19567fdb1723bc388.png
[70 4]: /images/20220523/79ae273602a249f7bc67289c19fa4e6a.png
[70 5]: /images/20220523/5a69a895ffa04f5aba9ee8dd424b7454.png
[70 6]: /images/20220523/04c3a41fb9b845e2bad6840234b67113.png
[70 7]: /images/20220523/b15b447b907b4834927dc49a18d42da7.png
[70 8]: /images/20220523/cb0aeec6d3cc49c5974170e89f766d3a.png
[70 9]: /images/20220523/44dcf499e7134f8e8600ad75ed8f311f.png
[https_blog.csdn.net_javazejian_article_details_72772461_volatile_E5_86_85_E5_AD_98_E8_AF_AD_E4_B9_89]: https://blog.csdn.net/javazejian/article/details/72772461#volatile%E5%86%85%E5%AD%98%E8%AF%AD%E4%B9%89