写在前面
在 可见性有序性,Happens-before来搞定 文章中,happens-before 的原则之一: volatile变量规则
对一个 volatile 域的写, happens-before 于任意后续对这个 volatile 域的读
按理说了解了这个规则,对 volatile 的使用就,,,,,,,,,已经足够了,但是面试官可是喜欢刨根问到底的,为了更透彻的了解 volatile 的内存语义与读写语义,为了面试多一些谈资进而获得一些加分项,同时尽早填补前序文章留下的坑,于是乎这篇文章就这样尴尬的诞生了
happens-before 之 volatile 变量规则
下面的表格你还记得吗?(是的,你记得😂)
能否重排序 | 第二个操作 | 第二个操作 | 第二个操作 |
---|---|---|---|
第一个操作 | 普通读/写 | volatile 读 | volatile 写 |
普通读/写 | - | - | NO |
volatile 读 | NO | NO | NO |
volatile 写 | - | NO | NO |
上面的表格是 JMM 针对编译器定制的 volatile 重排序的规则,那 JMM 是怎样禁止重排序的呢?答案是内存屏障
内存屏障 (Memory Barriers / Fences)
无论你听过这个名词与否都没关系,很简单,且看
为了实现 volatile 的内存语义,编译器在生成字节码时,会在指令序列中插入内存屏障来禁止特定类型的处理器重排序
这句话有点抽象,试着想象内存屏障是一面高墙,如果两个变量之间有这个屏障,那么他们就不能互换位置(重排序)了,变量有读(Load)有写(Store),操作有前有后,JMM 就将内存屏障插入策略分为 4 种:
- 在每个 volatile 写操作的前面插入一个 StoreStore 屏障
- 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障
- 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障
- 在每个 volatile 读操作的后面插入一个 LoadStore 屏障
1 和 2 用图形描述以及对应表格规则就是下面这个样子了:
3 和 4 用图形描述以及对应表格规则就是下面这个样子了:
其实图形也是表格内容的体现,只不过告诉大家内存屏障是如何禁止指令重排序的,所以大家只要牢记表格内容即可
一段程序的读写通常不会像上面两种情况这样简单,这些屏障组合起来如何使用呢?其实一点都不难,我们只需要将这些指令带入到文章开头的表格中,然后再按照程序顺序拼接指令就好了
来看一小段程序:
1 | public class VolatileBarrierExample { |
将屏障指令带入到程序就是这个样子:
我们将上图分几个角度来看:
- 彩色是将屏障指令带入到程序中生成的全部内容,也就是编译器生成的「最稳妥」的方案
- 显然有很多屏障是重复多余的,右侧虚线框指向的屏障是可以被「优化」删除掉的屏障
到这里你应该了解了 volatile 是如何通过内存屏障保证程序不被”擅自”排序的,那 volatile 是如何保证可见性的呢?
volatile 写-读的内存语义
回顾一下之前文章内容中的程序,假定线程 A 先执行 writer 方法,随后线程 B 执行 reader 方法:
1 | public class ReorderExample { |
到这里你是否还记得之前说过的 JMM,是的,你还记得😂,当线程 A 执行 writer 方法时,且看下图:
线程 A 将本地内存更改的变量写回到主内存中
volatile 读的内存语义:
当读一个 volatile 变量时, JMM 会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。
所以当线程 B 执行 reader 方法时,图形结构就变成了这个样子:
线程 B 本地内存变量无效,从主内存中读取变量到本地内存中,也就得到了线程 A 更改后的结果,这就是 volatile 是如何保证可见性的
如果你看过前面的文章你就不难理解上面的两张图了,综合起来说:
- 线程 A 写一个volatile变量, 实质上是线程 A 向接下来将要读这个 volatile 变量的某个线程发出了(其对共享变量所做修改的)消息
- 线程 B 读一个 volatile 变量,实质上是线程 B 接收了之前某个线程发出的(在写这个 volatile 变量之前对共享变量所做修改的)消息。
- 线程 A 写一个 volatile 变量, 随后线程 B 读这个 volatile 变量, 这个过程实质上是线程 A 通过主内存向线程B 发送消息。
到这里,面试 volatile 时,你应该有一些谈资了,同时也对 volatile 的语义有了更深层次的了解
彩蛋
之前的文章提到过这样一句话:
从内存语义的角度来说, volatile 的
写-读
与锁的释放-获取
有相同的内存效果;volatile 写和锁的释放有相同的内存语义; volatile 读与锁的获取有相同的内存语义
记住文中最后两张图, 当我们说到 synchronized 的时候,你就会猛的理解这句话的含义了, 感兴趣的可以自己先了解 synchronized 的写-读语义
接下来我们就聊一聊锁相关的内容了,敬请期待…
灵魂追问
- 如果 volatile 写之后直接 return,那还会生成 StoreLoad 指令吗?
- synchronized 是怎样逐步被优化的?