jmm内存模型_Java 内存模型 JMM

JMM，Java Memory Model，Java 内存模型。

什么是内存模型，要他何用？

假定一个线程为变量var赋值：var = 3;，内存模型要回答的问题是：在什么条件下，读取变量var的线程可以看到3这个值？

如果缺少了同步，线程可能无法看到其他线程操作的结果。导致这种情况的原因可以有：编译器生成指令的次序可以不同于源代码的“显然”版本，编译器还会把变量存储在寄存器而不是内存中；处理器可以乱序或并行执行指令；缓存会改变写入提交到主存得到变量的次序；存储在处理器本地缓存中的变量对其他处理器不可见 等等。

数据依赖性

如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时这两个操作之间就存在数据依赖性。数据依赖分下列三种类型：

名称　　　代码示例　　　　　说明

写后读　　a = 1;b = a;　　　写一个变量之后，再读这个位置。

写后写　　a = 1;a = 2;　　　写一个变量之后，再写这个变量。

读后写　　a = b;b = 1;　　　读一个变量之后，再写这个变量。

上面三种情况，只要重排序两个操作的执行顺序，程序的执行结果将会被改变。

编译器和处理器在重排序时，会遵守数据依赖性，编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。

as-if-serial语义

as-if-serial语义的意思指：不管怎么重排序，(单线程)程序的执行结果不能被改变。编译器、runtime 和处理器都必须遵守as-if-serial语义。

数据竞争

当程序未正确同步时，就会存在数据竞争。java内存模型规范对数据竞争的定义为：在一个线程中写一个变量，在另一个线程读同一个变量，而且写和读没有通过同步来排序。

顺序一致性模型

操作执行的顺序是唯一的，就是它们出现在程序中的顺序，这与执行它们的处理器无关；变量每一次读操作，都能得到执行序列上这个变量最新的写入值，无论这是哪个处理器写入的。这个是一个理想的模型，JMM是不支持的。

Java 语言规范规定了 JVM 要维护内部线程类似顺序语意(within-thread as-if-serial semantics)：只要程序的最终结果等同于它在严格的顺序环境中执行的结果，那么上述所有的行为都是允许的。

JMM 规定了 JVM 的一种最小保证：什么时候写入一个变量会对其他线程可见。

Java 内存模型

Java 内存模型的定义是通过动作(actions)的形式进行描述的，所谓动作，包括变量读和写、监视器加锁和释放锁、线程的启动和拼接(join)。

JMM为所有程序内部的动作定义了一个叫 happens-before 的偏序关系(偏序关系是反对称的、自反的和传递的关系)。如果操作 A 和 B 满足 happens-before 关系，那么执行动作 B 的线程就可以看到动作 A 的结果；如果两个操作之间没有 happens-before 关系，那么 JVM 就可以对它们随意地重排序。

happens-before法则

• 程序次序法则：线程中的每个动作 A 都 happens-before 于该线程中的每一个动作 B，其中，在程序中，所有的动作 B 都出现在动作 A 之后。(注：此法则只是要求遵循 as-if-serial语义)
• 监视器锁法则：对一个监视器锁的解锁 happens-before 于每一个后续对同一监视器锁的加锁。(显式锁的加锁和解锁有着与内置锁，即监视器锁相同的存储语意。)
• volatile变量法则：对 volatile 域的写入操作 happens-before 于每一个后续对同一域的读操作。(原子变量的读写操作有着与 volatile 变量相同的语意。)(volatile变量具有可见性和读写原子性。)
• 线程启动法则：在一个线程里，对 Thread.start 的调用会 happens-before 于每一个启动线程中的动作。
• 线程终止法则：线程中的任何动作都 happens-before 于其他线程检测到这个线程已终结，或者从 Thread.join 方法调用中成功返回，或者 Thread.isAlive 方法返回false。
• 中断法则法则：一个线程调用另一个线程的 interrupt 方法 happens-before 于被中断线程发现中断(通过抛出InterruptedException， 或者调用 isInterrupted 方法和 interrupted 方法)。
• 终结法则：一个对象的构造函数的结束 happens-before 于这个对象 finalizer 开始。
• 传递性：如果 A happens-before 于 B，且 B happens-before 于 C，则 A happens-before 于 C。

对于final域，编译器和处理器要遵守两个重排序规则：

• 在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作之间不能重排序。
• 初次读一个包含final域的对象的引用，与随后初次读这个final域，这两个操作之间不能重排序。

注意：

• 关于 final 域的内存语义，是在没有 this 引用逸出的前提下的。
• 对于依赖监视器锁法则的内存可见性，对共享变量变量的所有访问都必须在同步的情况下才有意义。

对于Java编程来说，需要关注的法则有：程序次序法则、监视器锁法则、volatile变量法则，还有 final 域的规则。

final 域与 this 引用逸出

this 引用逸出的举例：

public class ThisEscape {

private final int a; // final 域

public ThisEscape( int init, List list) {

// 对 final 域赋值, JMM 不保证这个写之后有 store barrier

a = init;

// 把 this 添加到一个外部集合，导致 this 引用逸出。

// 其他线程通过这个逸出的引用看到的 a 可能仍然是未初始化的值。

list.add( this );

// ... 其他构造语句

// 构造函数结束: store barrier; return;

}

}

JMM 对 final 域的保证可理解为它只会在构造函数返回之前插入一个存储屏障，保证构造函数内对 final 域的赋值在构造函数返回之前写到主存。

happens-before 举例说明

public class JMM {

int a ;

int b ;

int multi ;

volatile int sum ; //

public void order() {

int c = 12; // 1

int d = 34; // 2

// 作为方法内的局部变量，c、d 只能被当前线程访问，不存在数据竞争；

// 步骤 1 和 2 没有数据依赖，且它们之间没有限制重排序的操作，所以这两步之间 可以自由重排序。

multi = c * d; // 3

// 3 和 步骤 1、2 之间有数据依赖，所以 3 和 1、2 组成的整体之间不能重排序。

// 1、2 可能重排序了，所以说是整体。

sum = c + d; // 5

// insert store barrier here !!!!!

// 步骤 5 与 3 之间虽然没有数据依赖，但 volatile 的语义禁止两者之间的重排序。

// 执行完 store barrier 之后，其他线程都可以看到当前线程写入 sum 和 multi 的最新值。

int doubleTemp = multi * 2; // 5

// multi 是对象的属性，是共享变量，

// 如果有另一个线程进行写操作，由于对 multi 的访问没有进行同步，与当前线程的读操作存在数据竞争。

// 所以在多线程的情况下步骤 5 的执行结果是不确定的。

// insert load barrier here !!!!!

// volatile 变量的读操作之前会作废当前 CPU 的本地缓存，后续变量的访问需要重新从主存读取。

int doubleSum = sum * 2; // 8

// 由于 volatile 变量不具有互斥性，且当前方法没有使用锁进行同步，

// 所以步骤 8 读到的 sum 的值可能不是 步骤 5 写入的值(被其他线程修改了)。

}

}

深入理解 Java 内存模型是理解 JUC 包和编写高性能并发程序的基础。

可以通过JUC里同步器及其应用的源码分析去感受下内存模型的应用：

• JUC AQS
• JUC 源码分析 一 AbstractQueuedSynchronizer
• JUC 源码分析 二 ReentrantLock
• JUC 源码分析 三 AbstractQueuedSynchronizer 共享模式 与 CountDownLatch
• JUC 源码分析 四 wait notify notifyAll 与 条件对象

参考资料

• 深入理解Java内存模型 序列文章
• 《Java 并发编程实践》
• 内存屏障/栅栏 ( Memory Barriers / Fences )