Java内存模型

Java Memory Model，通过定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节，屏蔽掉各种硬件和操作系统的内存访问差异。

1.JMM的抽象结构

如下图所示，线程之间的共享变量(实例域，静态域和数组元素)存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存（Local Memory),本地内存中存储了该线程以读/写共享变量的副本。JMM决定一个线程对共享变量的写入何时对另一个线程可见。

在上图中，如果线程A和线程B要进行通信，必须要经历以下两个步骤：

1. 线程A把本地内存中A中更新近的共享变量刷新到主内存中去。
2. 线程B到主内存中去读取线程A之前已更新过的共享变量。

2.内存间的交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

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

3.重排序

重排序是指编绎器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段。重排序分为编译器优化的重排序，指令级并行的重排序和内存系统的重排序。从Java源代码到最终实际执行的指令序列，会分别经历这3种重排序，如下所示：

上图中的1属于编绎器重排序，2和3属于处理器重排序。

3.1 内存屏障

Memory Barrier，又称内存栅栏，是一个CPU指令，基本上它是一条这样的指令：
1、保证特定操作的执行顺序。
2、影响某些数据（或则是某条指令的执行结果）的内存可见性。

为了保证内存可见性，Java编绎器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序。JMM把内存屏障分为4类，如下所示：

3.2 happens-before

从jdk5开始，java使用新的JSR-133内存模型，基于happens-before的概念来阐述操作之间的内存可见性。

在JMM中，如果一个操作的执行结果需要对另一个操作可见，那么这两个操作之间必须要存在happens-before关系，这个的两个操作既可以在同一个线程，也可以在不同的两个线程中。

与程序员密切相关的happens-before规则如下：
1、程序顺序规则：一个线程中的每个操作，happens-before于该线程中任意的后续操作。
2、监视器锁规则：对一个锁的解锁操作，happens-before于随后对这个锁的加锁操作。
3、volatile域规则：对一个volatile域的写操作，happens-before于任意线程后续对这个volatile域的读。
4、传递性规则：如果 A happens-before B，且 B happens-before C，那么A happens-before C。

注意：两个操作之间具有happens-before关系，并不意味前一个操作必须要在后一个操作之前执行！仅仅要求前一个操作的执行结果，对于后一个操作是可见的，且前一个操作按顺序排在后一个操作之前。

3.3 数据依赖性

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

对于上面的3种情况，只要重排序两个操作的执行顺序，程序的执行结果就会被改变。编绎器和处理器在重排序时，会遵守数据依赖性，而不会改变存在数据依赖关系的两个操作的执行顺序。

3.4 as-if-serial

as-if-serial语义的意思是：不管怎么重排序（编绎器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。编绎器，runtime和处理器都必须遵守as-if-serial语义。

3.5 示例

为了具体说明，请看下面计算圆面积的代码示例：

double pi = 3.14; //A
double r = 1.0; //B
double area = pi * r * r; //C

上面3个操作的数据依赖关系如下图所示：

A和C之间存在数据依赖关系，同时B和C之间也存在数据依赖关系。因此在最终执行的指令序列中，C不能被重排序到A和B的前面（C排到A和B的前面，程序的结果将会被改变）。但A和B之间没有数据依赖关系，编译器和处理器可以重排序A和B之间的执行顺序。下图是该程序的两种执行顺序:

3.6 重排序对多线程的影响

先看如下示例代码：

class ReorderExample {
    int     a    = 0;
    boolean flag = false;

    public void writer() {
        a = 1; //1
        flag = true; //2
    }

    public void reader() {
        if (flag) { //3
            int i = a * a; //4
            //s……
        }
    }
}

flag变量是个标记，用来标识变量a是否已被写入。这里假设有两个线程A和B，A首先执行writer()方法，随后B线程接着执行reader()方法。线程B在执行操作4时，能否看到线程A在操作1对共享变量a的写入呢？
答案是：不一定能看到。
由于操作1和操作2没有数据依赖关系，编译器和处理器可以对这两个操作重排序；同样，操作3和操作4没有数据依赖关系，编译器和处理器也可以对这两个操作重排序。让我们先来看看，当操作1和操作2重排序时，可能会产生什么效果？请看下面的程序执行时序图，如下图所示：

上图中操作1和操作2做了重排序。程序执行时，线程A首先写标记变量flag，随后线B读这个变量。由于条件判断为真，线程B将读取变量a。此时，变量a还没有被线程A写入，在里多线程程序的语义被重排序破坏了！

下面再让我们看看，当操作3和操作4重排序时会产生什么效果（借助这个重排序，可便说明控制依赖性）。下面是操作3和操作4重排序后，程序执行的时序图，如下图所示:

在程序中，操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时，会影响指令序列执行的并行度。为此，编译器和处理器会采用猜测Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算a*a，然后把计算结果临时保存到一个名为重排序缓冲（Reorder Buffer，ROB）的硬件缓存中。当操作3的条件判断为真时，就把该计算结果写入变量i中。

从上图中我们可以看出，猜测执行实质上对操作3和4做了重排序。重排序在这里破坏了多线程程序的语义！

通过上例可以得出结论：在单线程程序中，对存在控制依赖的操作重排序，不会改变执行结果（这也是as-if-serial语义允许对存在控制依赖的操作做重排序的原因）；但在多线程程序中，对存在控制依赖的操作重排序，可能会改变程序的执行结果。