Java内存模型(JMM)以及happens-before原则

Java内存模型——JMM(Java Memory Model)

一、为什么要引入Java内存模型?

        主要是因为在多线程并发的情况下,由于CPU 优化,导致缓存不一致;或者因为编译器指令重排,多线程带来的结果不一致。为了解决这些并发的问题,让 Java 代码在不同硬件、不同操作系统中,输出的结果达到一致,Java 虚拟机规范提出了一套机制——Java 内存模型。下面就具体描述一下这些问题的产生。

1、缓存一致性:

        线程是 CPU 调度的最小单位,线程中的字节码指令最终都是在 CPU 中执行的。CPU在执行的时候,免不了要和各种数据打交道,而 Java 中所有数据都是存放在主内存(RAM)当中的,这一过程可以参考下图:


图1

        随着 CPU 技术的发展,CPU 的执行速度越来越快,但内存的技术并没有太大的变化,所以在内存中读取和写入数据的过程和 CPU 的执行速度比起来差距会越来越大,也就是上图中箭头部分。CPU 对主内存的访问需要等待较长的时间,这样就体现不出 CPU 超强运算能力的优势了。

        因此,为了“压榨”处理性能,达到“高并发”的效果,在 CPU 中添加了高速缓存 (cache)来作为缓冲。如图2


图2

        在执行任务时,CPU 会先将运算所需要使用到的数据复制到高速缓存中,让运算能够快速进行,当运算完成之后,再将缓存中的结果刷回(flush back)主内存,这样 CPU 就不用等待主内存的读写操作了。

        但是,每个处理器都有自己的高速缓存,同时又共同操作同一块主内存,当多个处理器同时操作主内存时,可能导致数据不一致,这就是缓存一致性问题

2、指令重排

        指令重排很好理解,就是在不影响结果的情况下,编译器进行了优化。例如一下java代码:

int a = 1;

int b = 2;

a = a + 1;

        对应的字节码:(可以通过javap -v xxx.class看到) 

         0: iconst_1       //将常量1压入操作数栈

         1: istore_1       //将栈顶元素保存到局部变量表下标1处

         2: iconst_2       //将常量2压入操作数栈

         3: istore_2       //将栈顶元素保存到局部变量表下标2处

         4: iload_1        //将局部变量表下标1处元素压入操作数栈

         5: iconst_1     //将常量1压入操作数栈

         6: iadd            //将栈顶的两个元素相加,并将结果压入操作数栈

         7: istore_1      //将栈顶元素保存到局部变量表下标1处

        可以看出在上述指令中,有两处指令表达的是同样的语义,并且指令 7 并不依赖指令 2 和指令 3。在这种情况下,CPU 会对指令的顺序做优化:

         0: iconst_1

         1: iconst_1

         2: iadd

         3: istore_1

         4: iconst_2

         5: istore_2

        从 Java 语言的角度看这层优化就是:

int a = 1;

a = a + 1;

int b = 2;

        也就是说在 CPU 层面,有时候代码并不会严格按照 Java 文件中的顺序去执行。

        所以有可能因为编译器重排,导致赋值先后顺序改变。这就导致了多线程中,由于赋值先后顺序改变,改变后又没有将结果刷回(flush back)主内存,因此导致结果不一致。

二、Java内存模型

        Java内存模型本质上是一套规范,是为了解决CPU 多级缓存、CPU 优化、指令重排等导致的内存访问问题,从而保证 Java 程序(尤其是多线程程序)在各种平台下对内存的访问效果一致。在这套规范中,有一个非常重要的规则——happens-before。

        在 Java 内存模型中,我们统一用工作内存(working memory)来当作 CPU 中寄存器或高速缓存的抽象。线程之间的共享变量存储在主内存(main memory)中,每个线程都有一个私有工作内存(类比 CPU 中的寄存器或者高速缓存),本地工作内存中存储了该线程读/写共享变量的副本。

happens-before 先行发生原则

        happens-before 用于描述两个操作的内存可见性,通过保证可见性的机制可以让应用程序免于数据竞争干扰。它的定义如下:

        如果一个操作 A happens-before 另一个操作 B,那么操作 A 的执行结果将对操作 B 可见。

        上述定义我们也可以反过来理解:如果操作 A 的结果需要对另外一个操作 B 可见,那么操作 A 必须 happens-before 操作 B。

1、程序次序规则

        在单线程内部,如果一段代码的字节码顺序也隐式符合 happens-before 原则,那么逻辑顺序靠前的字节码执行结果一定是对后续逻辑字节码可见,只是后续逻辑中不一定用到而已。比如以下代码:

int a = 10;  // 1

b = b + 1;   // 2

        当代码执行到 2 处时,a = 10 这个结果已经是公之于众的,至于用没用到 a 这个结果则不一定。比如上面代码就没有用到 a = 10 的结果,说明 b 对 a 的结果没有依赖,这样就有可能发生指令重排。

        但是如果将代码改为如下则不会发生指令重排优化:

int a = 10;  // 1

b = b + a;   // 2

2、锁定规则

        无论是在单线程环境还是多线程环境,一个锁如果处于被锁定状态,那么必须先执行 unlock 操作后才能进行 lock 操作。

3、变量规则

        volatile 保证了线程可见性。通俗讲就是如果一个线程先写了一个 volatile 变量,然后另外一个线程去读这个变量,那么这个写操作一定是 happens-before 读操作的。

4、线程启动规则

        Thread 对象的 start() 方法先行发生于此线程的每一个动作。假定线程 A 在执行过程中,通过执行 ThreadB.start() 来启动线程 B,那么线程 A 对共享变量的修改在线程 B 开始执行后确保对线程 B 可见。

5、线程中断规则

        对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测,直到中断事件的发生。

6、线程终结规则

        线程中所有的操作都发生在线程的终止检测之前,我们可以通过 Thread.join() 方法结束、Thread.isAlive() 的返回值等方法检测线程是否终止执行。假定线程 A 在执行的过程中,通过调用 ThreadB.join() 等待线程 B 终止,那么线程 B 在终止之前对共享变量的修改在线程 A 等待返回后可见。

你可能感兴趣的:(Java内存模型(JMM)以及happens-before原则)