您的位置:首页 > 编程语言 > Java开发

Java 内存模型 JMM

2014-03-15 00:02 330 查看
原文地址:http://coderbee.net/index.php/concurrent/20131219/650

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<Object> 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: http://coderbee.net/index.php/concurrent/20131205/600

JUC 源码分析 一 AbstractQueuedSynchronizer:http://coderbee.net/index.php/concurrent/20131209/614

JUC 源码分析 二 ReentrantLock:http://coderbee.net/index.php/concurrent/20131209/618

JUC 源码分析 三 AbstractQueuedSynchronizer 共享模式 与 CountDownLatch:http://coderbee.net/index.php/concurrent/20131213/631

JUC 源码分析 四 wait notify notifyAll 与 条件对象:http://coderbee.net/index.php/concurrent/20131220/653


参考资料

深入理解Java内存模型 序列文章
《Java 并发编程实践》
内存屏障/栅栏 ( Memory Barriers / Fences )
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: