内存屏障详解

内存屏障是硬件之上、操作系统或JVM之下，对并发作出的最后一层支持。再向下是是硬件提供的支持；向上是操作系统或JVM对内存屏障作出的各种封装。内存屏障是一种标准，各厂商可能采用不同的实现。

本文仅为了帮助理解JVM提供的并发机制。首先，从volatile的语义引出可见性与重排序问题；接下来，阐述问题的产生原理，了解为什么需要内存屏障；然后，浅谈内存屏障的标准、厂商对内存屏障的支持，并以volatile为例讨论内存屏障如何解决这些问题；最后，补充介绍JVM在内存屏障之上作出的几个封装。为了帮助理解，会简要讨论硬件架构层面的一些基本原理（特别是CPU架构），但不会深入实现机制。

内存屏障的实现涉及大量硬件架构层面的知识，又需要操作系统或JVM的配合才能发挥威力，单纯从任何一个层面都无法理解。本文整合了这三个层面的大量知识，篇幅较长，希望能在一篇文章内，把内存屏障的基本问题讲述清楚。
如有疏漏，还望指正！

volatile变量规则

一个用于引出内存屏障的好例子是volatile变量规则。

volatile关键字可参考猴子刚开博客时的文章volatile关键字的作用、原理。volatile变量规则描述了volatile变量的偏序 语义；这里从volatile变量规则的角度来讲解，顺便做个复习。

定义

volatile变量规则：对volatile变量的写入操作必须在对该变量的读操作之前执行 。

volatile变量规则只是一种标准，要求JVM实现保证volatile变量的偏序语义。结合程序顺序规则、传递性 ，该偏序语义通常表现为两个作用：

保持可见性

禁用重排序（读操作禁止重排序之后的操作，写操作禁止重排序之前的操作）

补充：

程序顺序规则：如果程序中操作A在操作B之前，那么在线程中操作A将在操作B之前执行。

传递性：如果操作A在操作B之前执行，并且操作B在操作C之前执行，那么操作A必须在操作C之前执行。

后文，如果仅涉及可见性，则指明“可见性”；如果二者均涉及，则以“偏序”代称。重排序一定会带来可见性问题，因此，不会出现单独讨论重排序的场景。

正确姿势

之前的文章多次涉及volatile变量规则的用法。

简单的仅利用volatile变量规则对volatile变量本身的可见性保证：

面试中单例模式有几种写法？：“饱汉 - 变种 3”在DCL的基础上，使用volatile修饰单例，以保证单例的可见性。

复杂的利用volatile变量规则（结合了程序顺序规则、传递性）保证变量本身及周围其他变量的偏序：

源码|并发一枝花之ReentrantLock与AQS（1）：lock、unlock：exclusiveOwnerThread借助于volatile变量state保证其相对于state的偏序。

源码|并发一枝花之CopyOnWriteArrayList：CopyOnWriteArrayList借助于volatile变量array，对外提供偏序语义。

可见性与重排序

前文多次提到可见性与重排序的问题，内存屏障的存在就是为了解决这些问题。到底什么是可见性？什么是重排序？为什么会有这些问题？

可见性

定义

可见性的定义常见于各种并发场景中，以多线程为例：当一个线程修改了线程共享变量的值，其它线程能够立即得知这个修改。

从性能角度考虑，没有必要在修改后就立即同步修改的值——如果多次修改后才使用，那么只需要最后一次同步即可，在这之前的同步都是性能浪费。因此，实际的可见性定义要弱一些，只需要保证：当一个线程修改了线程共享变量的值，其它线程在使用前，能够得到最新的修改值 。

可见性可以认为是最弱的“一致性”（弱一致），只保证用户见到的数据是一致的，但不保证任意时刻，存储的数据都是一致的（强一致）。下文会讨论“缓存可见性”问题，部分文章也会称为“缓存一致性”问题。

问题来源

一个最简单的可见性问题来自计算机内部的缓存架构：

缓存大大缩小了高速CPU与低速内存之间的差距。以三层缓存架构为例：

L1 Cache最接近CPU, 容量最小（如32K、64K等）、速度最高，每个核上都有一个L1 Cache。

L2 Cache容量更大（如256K）、速度更低, 一般情况下，每个核上都有一个独立的L2 Cache。

L3 Cache最接近内存，容量最大（如12MB），速度最低，在同一个CPU插槽之间的核共享一个L3 Cache。

准确地说，每个核上有两个L1 Cache, 一个存数据 L1d Cache, 一个存指令 L1i Cache。

单核时代的一切都是那么完美。然而，多核时代出现了可见性问题。一个badcase如下：

Core0与Core1命中了内存中的同一个地址，那么各自的L1 Cache会缓存同一份数据的副本。

最开始，Core0与Core1都在友善的读取这份数据。

突然，Core0要使坏了，它修改了这份数据，使得两份缓存中的数据不同了，更确切的说，Core1 L1 Cache中的数据失效了。

单核时代只有Core0，Core0修改Core0读，没什么问题；但是，现在Core0修改后，Core1并不知道数据已经失效，继续傻傻的使用 ，轻则数据计算错误，重则导致死循环、程序崩溃等。

实际的可见性问题还要扩展到两个方向：

除三级缓存外，各厂商实现的硬件架构中还存在多种多样的缓存，都存在类似的可见性问题 。例如，寄存器就相当于CPU与L1 Cache之间的缓存。

各种高级语言（包括Java）的多线程内存模型中，在线程栈内自己维护一份缓存是常见的优化措施，但显然在CPU级别的缓存可见性问题面前，一切都失效了 。

以上只是最简单的可见性问题，不涉及重排序等。
重排序也会导致可见性问题；同时，缓存上的可见性也会引起一些看似重排序导致的问题。

【文章福利】小编推荐自己的Linux内核技术交流群： 【977878001】整理一些个人觉得比较好得学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！前100进群领取，额外赠送一份 价值699的内核资料包（含视频教程、电子书、实战项目及代码）