【JUC】Volatile全解读

1、Volatile 定义

在多线程并发编程中synchronized和volatile都扮演着重要的角色,volatile是轻量级的synchronized,它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时,另外一个线程能读到这个修改的值。如果volatile变量修饰符使用恰当的话,它比synchronized的使用和执行成本更低,因为它不会引起线程上下文的切换和调度。

Java语言规范第3版中对volatile的定义如下:Java编程语言允许线程访问共享变量,为了确保共享变量能被准确和一致地更新,线程应该确保通过排他锁单独获得这个变量。Java语言提供了volatile,在某些情况下比锁要更加方便(读多写少)。如果一个字段被声明成volatile,Java线程内存模型确保所有线程看到这个变量的值是一致的

保证可见性;

禁止指令重排序

image-20221012141656022

2、Volatile 保障可见性

2.1 保障可见性概述

volatile是如何来保证可见性的呢?对volatile进行写操作时,CPU会做什么事情。

如 Java代码如下。

instance = new Singleton();         // instance是volatile变量*

转变成汇编代码,如下。

0x01a3de1d: movb $0×0,0×1104800(%esi);
0x01a3de24: lock addl $0×0,(%esp);

有volatile变量修饰的共享变量进行写操作的时候会多出第二行汇编代码,通过查IA-32架构软件开发者手册可知,Lock前缀的指令在多核处理器下会引发了两件事情。

(1)将当前处理器缓存行的数据写回到系统内存(主存。声言Lock信号。)。

(2)这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效。

2.2 详解

(1)Lock前缀指令会引起处理器缓存回写到主存。Lock前缀指令导致在执行指令期间,声言处理器的LOCK#信号。在多处理器环境中,LOCK#信号确保在声言该信号期间(执行期间),处理器可以独占任何共享内存(主存只有当前处理器一个人可以访问,锁总线)。但是,在最近的处理器里,LOCK#信号一般不锁总线,而是锁缓存,毕竟锁总线开销的比较大

对于Intel486和Pentium处理器,在锁操作时,总是在总线上声言LOCK#信号。但在P6和目前的处理器中,如果访问的内存区域已经缓存在处理器内部,则不会声言LOCK#信号。相反,它会锁定这块内存区域的缓存并回写到内存(总线锁定声言lock信号的,为了提高性能,高级的处理器走的是缓存锁定,改哪里锁定哪里,所以不需要声言lock信号。),并使用缓存一致性机制来确保修改的原子性,此操作被称为“缓存锁定”,缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据。

(2)一个处理器的缓存回写到内存会导致其他处理器的缓存无效。IA-32处理器和Intel 64处理器使用MESI(修改、独占、共享、无效)控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候,IA-32和Intel 64处理器能嗅探其他处理器访问系统内存和它们的内部缓存。处理器使用嗅探技术保证它的内部缓存、系统内存和其他处理器的缓存的数据在总线上保持一致。例如,在Pentium和P6 family处理器中,如果通过嗅探一个处理器来检测其他处理器打算写内存地址,而这个地址当前处于共享状态,那么正在嗅探的处理器将使它的缓存行无效,在下次访问相同内存地址时,强制执行缓存行填充。

为了提高处理速度,处理器不直接和内存进行通信,而是先将系统内存的数据读到内部缓存(L1,L2或其他)后再进行操作,但操作完不知道何时会写到内存。如果对声明了volatile的变量进行写操作,JVM就会向处理器发送一条Lock前缀的指令,将这个变量所在缓存行的数据写回到系统内存。但是,就算写回到内存,如果其他处理器缓存的值还是旧的,再执行计算操作就会有问题。所以,在多处理器下,为了保证各个处理器的缓存是一致的,就会实现缓存一致性协议,每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了,当处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状态,当处理器对这个数据进行修改操作的时候,会重新从系统内存中把数据读到处理器缓存里。

3、Volatile优化案例

著名的Java并发编程大师Doug lea在JDK 7的并发包里新增一个队列集合类Linked-TransferQueue,它在使用volatile变量时,用一种追加字节的方式来优化队列出队和入队的性能。LinkedTransferQueue的代码如下。

image-20221012142148421

3.1 追加字节能优化性能?

这种方式看起来很神奇,但如果深入理解处理器架构就能理解其中的奥秘。让我们先来看看LinkedTransferQueue这个类,它使用一个内部类类型来定义队列的头节点(head)和尾节点(tail),而这个内部类PaddedAtomicReference相对于父类AtomicReference只做了一件事情,就是将共享变量追加到64字节。我们可以来计算下,一个对象的引用占4个字节,它追加了15个变量(共占60个字节),再加上父类的value变量,一共64个字节。

3.2 为什么追加64字节能够提高并发编程的效率呢?

因为对于英特尔酷睿i7、酷睿、Atom和NetBurst,以及Core Solo和Pentium M处理器的L1、L2或L3缓存的高速缓存行是64个字节宽,不支持部分填充缓存行,这意味着,如果队列的头节点和尾节点都不足64字节的话,处理器会将它们都读到同一个高速缓存行中,在多处理器下每个处理器都会缓存同样的头、尾节点,当一个处理器试图修改头节点时,会将整个缓存行锁定,那么在缓存一致性机制的作用下,会导致其他处理器不能访问自己高速缓存中的尾节点,而队列的入队和出队操作则需要不停修改头节点和尾节点,所以在多处理器的情况下将会严重影响到队列的入队和出队效率。Doug lea使用追加到64字节的方式来填满高速缓冲区的缓存行,避免头节点和尾节点加载到同一个缓存行,使头、尾节点在修改时不会互相锁定。

那么是不是在使用volatile变量时都应该追加到64字节呢?不是的。在两种场景下不应该使用这种方式。

  • 缓存行非64字节宽的处理器。如P6系列和奔腾处理器,它们的L1和L2高速缓存行是32个字节宽。
  • 共享变量不会被频繁地写。因为使用追加字节的方式需要处理器读取更多的字节到高速缓冲区,这本身就会带来一定的性能消耗,如果共享变量不被频繁写的话,锁的几率也非常小,就没必要通过追加字节的方式来避免相互锁定

4、Volatile 禁止指令重排序

4.1 概述

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

下面是基于保守策略的JMM内存屏障插入策略:

  • 在每个 volatile 写操作的前面插入一个 StoreStore 屏障,防止前面的store与当前的store发生指令重排序

  • 在每个 Volatile 写操作的后面插入一个 StoreLoad 屏障,防止当前的store操作与后面的load操作发生指令重排序

  • 在每个 Volatile 读操作的后面插入一个 LoadLoad 屏障,防止当前的load操作与后面的load操作发生指令重排序

  • 在每个 Volatile 读操作的后面插入一个 LoadStore 屏障,防止当前的Load操作与后面的Store操作发生指令重排序

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

4.2 Volatile 写操作

保守策略下,Volatile 写插入内存屏障后生成的指令序列示意图

image-20221012143311745

如图:StoreStore屏障可以保证在volatile写之前,其前面的所有普通写操作已经对任意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存。

这里比较有意思的是,volatile写后面的StoreLoad屏障。此屏障的作用是避免volatile写与后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile写的后面是否需要插入一个StoreLoad屏障(比如,一个volatile写之后方法立即return)。为了保证能正确实现volatile的内存语义,JMM在采取了保守策略:在每个volatile写的后面,或者在每个volatile读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑,JMM最终选择了在每个volatile写的后面插入一个StoreLoad屏障。因为volatile写-读内存语义的常见使用模式是:一个写线程写volatile变量,多个读线程读同一个volatile变量(选择在一个写线程Volatile写之后创建StoreLoad屏障,而不是在多个读线程volatile读之前加StoreLoad屏障)。当读线程的数量大大超过写线程时,选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM在实现上的一个特点:首先确保正确性,然后再去追求执行效率。

4.3 Volatile 读操作

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

image-20221012143804928

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

4.4 总结

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

image-20221012143912408

image-20221012143922712

5、Volatile 内存语义增强

5.1 Volatile 读写与普通读写之间为什么要禁止重排序

问题:为什么在Volatile中要禁止Volatile读写与普通读写之间的重排序?

JSR-133之前的旧Java内存模型中,虽然不允许volatile变量之间重排序,但旧的Java内存模型允许volatile变量与普通变量重排序。这样会产生问题

image-20221013111139645

在旧的内存模型中,当1和2之间没有数据依赖关系时,1和2之间就可能被重排序(3和4类似)。其结果就是:读线程B执行4时,不一定能看到写线程A在执行1时对共享变量的修改。

image-20221013111227353

5.2 JSR-133增强 Volatile 的内存语义

image-20221013111502499

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

6、双重检查锁问题根源

未使用 Volatile 下的双重检查锁

双重检查锁的示例代码:

image-20221013111810229

上述代码中第 7 行instance = new Singleton();,创建了一个对象,这一行代码可以分解为如下 3 行伪代码

memory = allocate(); //(1)分配对象的内存空间
ctroInstance(memory); //(2)初始化对象
instance = memory; //(3)设置instance指向刚分配的内存地址

上述 3 行伪代码中,第 2 行和第 3 行之间可能会发生指令重排序,如下

memory = allocate(); //(1)分配对象的内存空
instance = memory; //(3)设置instance指向刚分配的内存地址
				   //注意:此时对象还没有被初始化,但是instance已经有内存地址了,在实例代码的if判断中,instance不为null,如果另一个线程执行到实例代码第4行,就会认为instance对象已经初始化完成了,直接返回
ctroInstance(memory); //(2)初始化对象

7、双重检查锁两种解决办法

7.1 基于 Volatile 的解决方案

image-20221013112902761

大众式的讲解。因为面试过程中,绝大多数面试官都认为是volatile禁止了 new 对象里边三行代码的重排序

校长:因为new instance 他是一个 JVM 指令码,对应的是 new 指令。 Volatile能够保障单个JVM 指令的原子性,所以此处, new instace相当于是volatiole写,会在 new instance前加 storestore,后加storeload屏障,b线程就必须在storeload 屏障后边读取。(不建议面试使用。)实质上,new对象里边的三个小步骤,依然可以重排序,真正的控制是在外层的内存屏障控制。

7.2 基于类初始化的解决方案

JVM在类的初始化阶段(即在Class被加载后,且被线程使用之前),会执行类的初始化。在执行类的初始化期间,JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。

image-20221013113423749

image-20221013113443993

posted @   DarkSki  阅读(130)  评论(0编辑  收藏  举报
努力加载评论中...
点击右上角即可分享
微信分享提示