Java 内存模型

2017-12-27 本文已影响0人 panning

一、Java 内存模型的主要目标

Java 内存模型的主要目标是 定义程序中各个变量的访问规则，即在虚拟机中 将变量存储到内存 和 从内存中取出变量 这样的底层细节。此处的变量（Variables）与 Java 变成中所说的变量有所区别，它包括了实例变量、静态变量和构成数组对象的元素，但不包括局部变量与方法参数，因为后者是线程私有的，不会被共享，自然就不会存在竞争问题。

为了获得较好的执行效能，Java 内存模型并没有限制执行引擎使用处理器的特定寄存器或缓存来和主内存进行交互，也没有限制即时编译器进行调整代码执行顺序这类优化措施。

二、主内存与工作内存

Java 内存模型规定了所有的变量都存储在主内存（Main Memory，这里指的是虚拟机内存的一部分）中。每条线程还有自己的工作内存（Working Memory，可以与处理器高速缓存类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。

不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成，线程、主内存、工作内存三者的交互关系如下图所示。

线程、主内存、工作内存三者的交互关系

这里说的主内存、工作内存和 Java 内存区域中的 Java 堆、栈、方法区等并不是同一个层次的内存划分，这两者基本是没有关系的，如果两者一定要勉强对应起来的话，那从变量、主内存、工作内存的定义来看，主内存主要对应于 Java 堆中的对象实例数据部分，而工作内存则对应于 Java 虚拟机栈中的部分区域。

三、内存件交互操作

关于主内存和工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java 内存模型中定义了一下 8 中操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的（对于 double 和 long 类型的变量来说，在某些平台上允许有例外，这个问题将在下文中说明）。

lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后变量才可以被其他线程锁定。
read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到工作内存中，以便随后的 load 动作使用。
load（载入）：作用于工作内存的变量，它把 read 操作从主内存得到的变量值保存到工作内存的变量副本中。
use（使用）：作用于工作内存的变量，它把工作内存中的一个变量的值传递给执行引擎（一般是基于操作数栈的执行引擎），每当虚拟机遇到一个需要使用到该变量的值的字节码指令时将会执行这个操作。
assign（赋值）：作用于工作内存的变量，它把从执行引擎接收到的值赋值给工作内存的变量（存放在局部变量表中），每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
store（存储）：作用于工作内存的变量，它把工作内存中的变量传送到主内存中，以便随后的 write 操作使用。
write（写入）：作用于主内存的变量，它把 store 操作从工作内存中得到的变量的值方法主内存的变量中。

其中 read、load、use、assign、store 和 write 这 6 种操作的关系如下图所示。

点击看大图

Java 内存模型规定了在执行上述 8 中基本操作时必须满足如下规则：

不允许 read 和 load、store 和 write 操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者工作内存发起会回写了但主内存不接受的情况出现。
不允许一个现场丢弃它的最近的 assign 操作，即变量的值在工作内存改变了以后必须把该变化同步到主内存中。
不允许一个线程无原因的（没有发生过任何 assing 操作）把数据从线程的工作内存同步回主内存中。
一个新的变量只能在主内存中“诞生”，不允许在工作内存使用一个未被初始化（load 或 assing）的变量，换句话说，就是对一个变量实施 use、store 操作之前，必须先执行过 assign 和 load 操作。
一个变量在同一个时刻只允许一条线程对其进行 lock 操作，但 lock 操作可以被同一线程重复执行多次，多次执行 lock 之后，只有执行相同次的 unlock 操作，变量才会被解锁。
如果对一个变量进行 lock 操作，那么将会清空工作内存中这个变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作初始化变量的值。
如果一个变量事先没有被 lock 操作锁定，那就不允许对它执行 unlock 操作，也不允许去 unlock 一个被其他线程锁定住的变量。
对一个变量执行 unlock 之前，必须先把此变量同步回主内存中（执行 store 以及 write 操作）。
这 8 中内存方法操作以及上述规则限定，再加上稍后 volatile 的一些特殊规定，就已经完全确定了 Java 程序中哪些内存访问操作在并发下是安全的。

四、对于 volatile 型变量的特殊规则

当一个变量定义为 volatile 之后，它将具备两种特性：保证变量的可见性 和 禁止指令重排序优化。

第一个是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程改变了这个变量的值，新值对于其他线程来说是 立即得知 的。而普通变量做不到这一点，普通变量的值在线程间传递均需要通过主内存来完成，例如，线程 A 修改了一个普通变量的值，然后向主内存进行回写，另外一个线程 B 在线程 A 回写完成了之后再从主内存进行读取操作，新变量才会对线程 B 可见。
关于 volatile 变量的可见性，写操作在并发下是安全的，但是 volatile 变量的运算在并发下不是安全 的，因为 Java 里面的运算并非原子操作。
使用 volatile 变量的第二个语义是禁止指令重排序优化，普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

了解了volatile 的语义问题，那么我们来比较一下 使用 volatile 的代码和使用其他的同步工具更快哪个更快？

在某些情况下，volatile 的同步机制的性能确实要优于（使用 synchronized 关键字或 java.util.concurrent 包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难量化地认为 volatile 就会比 synchronized 块多少。如果让 volatile 自己与普通变量比较：volatile 变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。

最后看一下 Java 内存模型对 volatile 变量定义的特殊规则。假定 T 表示一个线程， V 和 W 分别表示两个 volatile 型变量，那么在进行 read、load、use、assign、store 和 write 操作时需要满足如下规则：

只有当线程 T 对变量 V 执行的前一个动作是 load 的时候，线程 T 才能对变量 V 执行 use 动作；并且，只有当线程 T 对变量 V 执行的后一个动作是 use 的时候，线程 T 才能对变量 V 执行 load 动作。线程 T 对变量 V 的 use 动作可以认为是和线程 T 对变量 V 的 load、read 动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次使用 V 前都必须先冲主内存刷新最新的值，用于保证能看见其他线程对变量 V 所做的修改后的值）。
只有当线程 T 对变量 V 执行的前一个动作是 assign 的时候，线程 T 才能对变量 V 执行 store 动作；并且，只有当线程 T 对变量 V 执行的后一个动作是 store 的时候，线程 T 才能对变量 V 执行 assign 动作。线程 T 对变量 V 的 assign 动作可以认为是和线程 T 对变量 V 的 store、write 动作相关联，必须连续一起出现（这条规则要求在工作内存中，每次修改 V 后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量 V 所做的修改）。
假定动作 A 是线程 T 对变量 V 实施的 use 或 assign 动作，假定动作 F 是和动作 A 相关联的 load 或 store 动作，假定动作 P 是和动作 F 相应的对变量 V 的 read 或 write 动作；类似的，假定动作 B 是线程 T 对变量 W 实施的 use 或 assign 动作，假定动作 G 是和动作 B 相关联的 load 或 store 动作，假定动作 Q 是和动作 G 相应的对变量 W 的 read 或 write 动作。如果 A 先于 B，那么 P 先于 Q（这条规则要求 volatile 修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序相同）。

五、对于 long 和 double 型变量的特殊规则

Java 内存模型要求 lock、unlock、read、load、use、assign、store、write 这 8 个操作都具有原子性，但是对于 64 位的数据类型（long 和 double），在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被 volatile 修饰的 64 位数据的读写操作划分为两次 32 位的操作来进行，即允许虚拟机实现选择可以不保证 64 位数据类型的 load、store、read 和 write 这 4 个操作的原子性。

不过，在实际开发中，目前各种平台下的商用虚拟机几乎都选择把 64 位的数据的读写操作作为院子操作来对待，因此我们在编写代码时一般不需要把用到的 long 和 double 变量专门声明为 volatile。

六、原子性、可见性与有序性

Java 内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这 3 个特征来建立的。

原子性（Atomicity）：由 Java 内存模型来直接保证的原子性变量操作包括 read、load、use、assign、store 和 write，我们大致可以认为 基本数据类型 的访问读写是具备原子性的（例外就是 long 和 double 的非原子协定）。
如果应用场景需要一个更大范围（包括基本数据类型以外的变量）的原子性保证，Java 内存模型还提供了 lock 和 unlock 操作来满足这种需求，尽管虚拟机未把 lock 和 unlock 操作直接开发给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作，这两字节码指令反映到 Java 代码中就是同步块——synchronized 关键字，因此在 synchronized 块之间的操作也具备原子性。
也就是说 Java 内存模型中的 read、load、use、assign、store 和 wriet 这 6 种操作可以保证 基本数据类型 的原子性，而 Java 内存模型定义的 lock 和 unlock 操作则可以保证基本数据类型以外的数据类型的原子性。
可见性（Visibility）：可见性是指一个线程修改了一个变量的值，其他线程可以立即得知这个修改。Java 内存模型是通过在工作内存中变量修改后将新值立即同步回主内存，在工作内存中变量读取前从主内存刷新新变量的值这种依赖主内存作为传递媒介的方式来实现可见性的。无论是普通变量还是 volatile 变量都是如此，普通变量与 volatile 变量的区别是，volatile 的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说 volatile 保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。
除了 volatile 之外，Java 还有两个关键字能实现可见性，即 synchronized 和 final。同步块的可见性是由“对一个变量执行 unlock 操作之前，必须先把工作内存中此变量的值同步回主内存中（执行 store、write 操作）”这条规则获得的，而 final关键字的可见性是指：被 final 修饰的字段在构造器中一旦初始化完成，并且构造器没有把 “this” 引用传递出去，那在其他线程中就能看见 final 字段的值。
有序性（Ordering）：Java 程序中天然的有序性可以总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指“线程内表现为串行的语义”，后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。
Java 语言提供了 volatile 和 synchronized 两个关键字来保证线程之间操作的有序性，volatile 关键字本身就包含了进制指令重排序的语义，而 synchronized 则是由“一个变量在同一个时刻只允许一条线程对其进行 lock 操作”这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行的进入。

介绍完并发中 3 中重要的特性后，有没有发现 synchronized 关键字在需要 3 中特性的时候都可以作为其中一种的解决方案。

七、先行发生原则

如果 Java 内存模型中所有的有序性都仅仅靠 volatile 和 synchronized 来完成，那么有一些操作将会变得很烦琐，但是我们在编写 Java 并发代码的时候并没有感觉到这一点，这是因为 Java 语言中有一个 “先行发生”（happens-before）的原则。这个原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们可以通过几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题。

下面是 Java 内存模型下一些“天然的”先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来的话，它们就没有顺序性保障，虚拟机可以对它们随意的进行重排序。

程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准备的说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
管程锁定规则：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。
volatile 变量规则：对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。
线程启动规则：Thread 对象的 start() 方法先行发生于此线程的每一个动作。
线程终止规则：线程中的所有操作都先行于对此线程的终止检测，我们可以通过 Thread.join() 方法结束、Thead.isAlive() 的返回值等手段检测到线程已经终止执行。
线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 Thread.interrupted() 方法检测到是否有中断发生。
对象终结规则：一个对象的初始化完成（构造函数执行结束）先行于发生于它的 finalized() 方法的开始。
传递性：如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那就可以得出操作 A 先行发生于操作 C 的结论。