欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Java 内存模型 JMM

程序员文章站 2022-07-13 16:00:19
...

 

原文地址: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

 

参考资料