Java 内存模型的作用

《Java虚拟机规范》中曾试图定义一种“Java内存模型”（Java Memory Model，JMM）来屏蔽各种硬件和操作系统的内存访问差异， 以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

在此之前， 主流程序语言（如 C 和 C++ 等） 直接使用物理硬件和操作系统的内存模型。 因此， 由于不同平台上内存模型的差异， 有可能导致程序在一套平台上并发完全正常， 而在另外一套平台上并发访问却经常出错， 所以在某些场景下必须针对不同的平台来编写程序。

主内存 & 工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。

Java内存模型规定了所有的变量都存储在主内存（Main Memory） 中（此处的主内存与介绍物理硬件时提到的主内存名字一样， 两者也可以类比， 但物理上它仅是虚拟机内存的一部分） 。每条线程还有自己的工作内存（Working Memory， 可与前面讲的处理器高速缓存类比） ， 线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、 赋值等） 都必须在工作内存中进行， 而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量， 线程间变量值的传递均需要通过主内存来完成。

此处的变量（Variables） 与 Java 编程中所说的变量有所区别。

此处的变量包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数，因为局部变量与方法参数是线程私有的，不会被共享，自然就不会存在竞争问题。

线程、主内存、工作内存三者的交互关系如图所示。

内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节， Java内存模型中定义了以下 8 种内存访问操作来完成。

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

Java虚拟机实现时必须保证上面提及的每一种内存访问操作都是原子的、不可再分的（对于 double 和 long 类型的变量来说，load、 store、 read 和 write 操作在某些平台上允许有例外， 这个问题会专门讨论）。

如果要把一个变量从主内存拷贝到工作内存， 那就要按顺序执行 read 和 load 操作，如果要把变量从工作内存同步回主内存， 就要按顺序执行 store 和 write 操作。

注意， Java 内存模型只要求上述两个操作必须按顺序执行， 但不要求是连续执行。也就是说 read 与 load 之间、 store 与 write 之间是可以插入其他指令的， 如对主内存中的变量 a、 b 进行访问时，一种可能出现的顺序是 read a、read b、load b、load a。

除此之外， Java 内存模型还规定了在执行上述 8 种内存访问操作时必须满足如下规则：

• 不允许 read 和 load、 store 和 write 操作之一单独出现， 即不允许一个变量从主内存读取了但工作内存不接受， 或者工作内存发起回写了但主内存不接受的情况出现。
• 不允许一个线程丢弃它最近的 assign 操作， 即变量在工作内存中改变了之后必须把该变化同步回主内存。
• 不允许一个线程无原因地（没有发生过任何 assign 操作） 把数据从线程的工作内存同步回主内存中。
• 一个新的变量只能在主内存中“诞生”， 不允许在工作内存中直接使用一个未被初始化（未执行 load 或 assign 操作） 的变量， 换句话说就是对一个变量实施 use、 store 操作之前， 必须先执行 load、assign 操作。
• 一个变量在同一个时刻只允许一条线程对其进行 lock 操作， 但 lock 操作可以被同一条线程重复执行多次，多次执行 lock 后， 只有执行相同次数的 unlock 操作， 变量才会被解锁。
• 如果对一个变量执行 lock 操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作以初始化变量的值。
• 如果一个变量事先没有被 lock 操作锁定， 那就不允许对它执行 unlock 操作， 也不允许去 unlock 一个被其他线程锁定的变量。
• 对一个变量执行 unlock 操作之前， 必须先把此变量同步回主内存中（执行 store 和 write 操作） 。

这 8 种内存访问操作以及上述规则限定， 再加上稍后会介绍的专门针对 volatile 的一些特殊规定， 就已经能准确地描述出 Java 程序中哪些内存访问操作在并发下是安全的。

针对 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 修饰的变量不会被指令重排序优化， 从而保证代码的执行顺序与程序的顺序相同。

先行发生原则

先行发生原则（Happens-Before）是Java内存模型定义的一个等效判断原则。依赖这个原则， 我们可以通过几条简单规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题， 而不需要陷入Java内存模型苦涩难懂的定义之中。

“先行发生”原则指的是什么。 先行发生是Java内存模型中定义的两项操作之间的偏序关系， 比如说操作 A 先行发生于操作 B， 其实就是说在发生操作 B 之前， 操作 A 产生的影响能被操作 B 观察到， “影响”包括修改了内存中共享变量的值、 发送了消息、 调用了方法等。

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

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

Java 语言无须任何同步手段保障就能成立的先行发生规则有且只有上面这些。

“时间上的先后顺序”与“先行发生”之间有什么不同？一个操作“时间上的先发生”不代表这个操作会是 “先行发生”。那如果一个操作“先行发生”， 是否就能推导出这个操作必定是“时间上的先发生”呢？ 很遗憾， 这个推论也是不成立的。

时间先后顺序与先行发生原则之间基本没有因果关系，所以我们衡量并发安全问题的时候不要受时间顺序的干扰， 一切必须以先行发生原则为准。

参考资料

《深入理解Java虚拟机》第 12 章：Java 内存模型与线程 12.3 Java 内存模型