# Java内存模型

Java内存模型，即JMM（Java Memery Model），它的主要目标是定义程序中各个**变量的访问规则**，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。Java虚拟机规范试图通过定义这样一种模型来屏蔽各种硬件和操作系统的内存访问差异。

此处的变量是指**包括实例字段、静态字段和构成数组对象的元素，但不包括局部变量和方法参数**，因为后者是线程私有的，不会被共享，不存在竞争问题。

## 主内存与工作内存

![主内存和工作内存.png](http://upload-images.jianshu.io/upload_images/1932449-ac4ecc49655c05c2.png?imageMogr2/auto-orient/strip|imageView2/2/w/1240)

* 所有的变量都存储在主内存，每条线程还有自己的工作内存。线程的工作内存保存了该线程使用到的变量的主内存的副本。（这里的副本拷贝并不是真正的内存复制，虚拟机会通过不同的实现方式达到这种效果）。
* 线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。
* 不同线程之间不能直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。
* 从更低层次来将，主内存直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

## 内存间交互操作

Java内存模型中定义了**8种操作**来完成**主内存和工作内存之间的交互**：如何将变量从主内存拷贝到工作内存、如何将变量从工作内存同步回主内存。

这8中操作每一个都是**原子性的、不可再分**的。

| 操作     | 变量域  | 作用                              |
| ------ | ---- | ------------------------------- |
| lock   | 主内存  | 将变量标识为一条线程独占的状态                 |
| unlock | 主内存  | 将处于锁定状态的变量释放，之后才可以再被其他线程锁定      |
| read   | 主内存  | 将变量值从主内存传输到工作内存                 |
| load   | 工作内存 | 将read操作从主内存得到的变量放入工作内存的变量副本中    |
| use    | 工作内存 | 将工作内存中的变量的值传递给执行引擎使用            |
| assign | 工作内存 | 把从执行引擎中接受到的值赋给工作内存              |
| store  | 工作内存 | 将工作内存中变量的值传输到主内存中               |
| write  | 主内存  | 将store操作从工作内存中得到的变量的值放入主内存中的变量中 |

假如主内存中存在变量`var`，工作内存中存在变量`var`的副本`var_copy`：先通过对`var`执行`read`操作，将`var`的值传输到工作内存中；再对`var_copy`执行`load`操作将传来的值赋给`var_copy`；当执行引擎执行使用到该变量的字节码指令时，对`var_copy`执行`use`操作将`var_copy`的值传输给执行引擎；执行引擎执行结束后，对`var_copy`执行`assign`操作，将执行引擎传输来的值赋给`var_copy`；对`var_copy`执行`store`操作，将`var_copy`的值传输到主内存，对`var`执行`write`操作，将传输来的值赋给`var`。

执行上述8种操作时必须满足如下8种规则：

* 执行顺序相关的规则
  * `read load`必须同时出现，`store write`必须同时出现
  * 执行`assign`后就必须执行`store write`：变量在工作内存改变后必须同步回主内存
  * 不执行`assign`就不能必须`store write`：不能无原因地将数据从工作内存同步到主内存
  * `use`之前必须先`read load`：不能直接使用主内存中的变量
* lock和unlock相关的规则
  * 一个变量在同一时刻只允许一个线程对其进行`lock`操作，但可被同一线程多次`lock`，多次`lock`后必须执行相同次数的`unlock`，变量才能被解锁。
  * 对一个变量执行`lock`，就会清空工作内存中该变量的值，在执行引擎使用这个变量的时候，必须重新`load`或`assign`来初始化变量的值。
  * 不能去`unlock`一个没有`lock`的变量，不能`unlock`被其他线程`lock`的变量
  * 对变量`unlock`之前，必须先`store write`：解锁前必须将变量同步到主内存中。

## 原子性、可见性、有序性

Java内存模型是围绕着在并发过程中如何处理原子性、可见性、有序性这三个特征来建立的。

* **原子性**\
  这里所说的原子性是指某操作具有原子性，即原子操作。\
  原子操作是指不会被线程调度机制打断的操作，这种操作一旦开始，就一直运行到结束，中间不会切换到另一个线程。\
  ①Java内存模型中的原子操作包括read、load、use、assign、store、write。\
  ②Java语法层面，基本数据类型的访问读写都是原子操作。

  ```
  比如a=5这个给a赋值的操作时原子性的，但a = a + 1就不是原子性的；
  ```

  但是，在实际应用中，通常需要更大范围的原子性保证，比如上面的`a = a + 1`操作。Java内存模型提供了lock和unlock来满足这种需求，虽然这两个操作并未开放给用户使用，但却提供了更高层次的字节码指令monitorenter和monitorexit来隐士地使用这两个操作。这两个字节码指令反映到Java代码中就是同步块——`synchronized`关键字。因此在`synchronized`块之间的操作也具备原子性。
* **可见性**\
  是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。\
  Java内存模型是通过将新值同步回主内存，在变量读取前从主内存刷新变量这种依赖主内存作为传递媒介的方式来实现可见性的。\
  ①无论是普通变量还是volatile变量都是如此，只不过volatile关键字保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。\
  ②**除了volatile关键字，**`synchronized`**和**`final`**关键字也能实现可见性**。同步块的可见性是由“对变量unlock之前，必须先`store write`将变量从工作内存同步到主内存”这条规则获得的。而`final`的可见性是指：被`final`修饰的字段在构造器中一旦初始化完成，并且构造器没有把`this`的引用传递出去，那在其他线程就能看见final字段的值。
* **有序性**
  * **Java程序中天然的有序性**

    ①如果在本线程内观察，所有的操作都是有序的（线程内表现为串行的语义）

    ②如果在一个线程观察另外一个线程，所有的操作都是无序的（指令重排序现象和工作内存与主内存同步延迟现象）
  * `volatile`**和**`synchronized`**保证线程之间的有序性**

    ①`volatile`本身就包含了禁止指令重排序的语义

    ②`synchronized`则是由“一个变量一个时刻只允许一条线程对其进行lock”这条规则获得的，这条规则决定了持有同一个锁的同步块只能串行地进入。

## volatile型变量的特殊规则

Java内存模型对volatile专门定义了一些特殊的访问规则。

* `read load use`必须连续出现，中间不能出现别的操作（每次`use`之前必须是`load`）：保证看见其他线程的对变量的修改。
* `assign store write`必须连续出现，中间不能出现别的操作（每次`assign`之后必须是`store`）：保证每次在工作内存中修改变量值后都立即同步到主内存。
* 两个`volatile`型变量A和B，如果线程T对A的`use（或assign）`先于线程T对B的`use（或assign）`，那么线程T对A的`read（或write）`先于线程T对B的`read（或write）`：保证volatile修饰的变量不会被重排序优化，保证代码的执行顺序与程序的顺序相同。

通过上述的访问规则可以看出，volatile的实现（或者说volatile的同步机制）是没有用到lock操作的（无锁）。

正是由于上述特殊的访问规则，才使得volatile关键字修饰的变量具有如下两个特征：

* **可见性**  \
  当一个变量被定义为volatile之后，当一个线程修改了这个变量的值，其他线程可以立即得知。假如有变量var，线程1和线程2，如果var是普通变量，线程1修改var的值之后，然后向主内存进行回写。线程2假如在线程1修改var值之后、回写之前对变量var进行了读操作，此时仍然是旧值（不安全）。如果var是volatile变量，那么无论线程2何时读var的值，var的值都是最新的：**对volatile变量的所有的写操作都能立即反应到其他线程中，volatile变量对所有线程是立即可见的**。但由于Java中的运算并不是原子的，如果对volatile变量进行并发运算，一样是不完全的。\
  满足以下两条规则的场景可以保证volatile的并发安全：\
  ①运算结果不依赖volatile变量的当前值，或者能够保证只有单一的线程修改volatile变量的值；\
  ②volatile变量不需要与其他的状态变量共同参与不变约束。\
  ③下面这种场景很适合volitile来控制并发，当调用`stop()`方法后，能保证所有献线程中执行的`doWork()`方法都立即停下来。

  ```
  volatile boolean shouldStop = false;
  public void stop(){
      shouldStop = true;
  }    
  public void doWork(){
      while (!shouldStop){
            //do something
      }
  }
  ```
* **禁止指令重排序优化**\
  普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，但不会保证变量赋值操作的顺序与程序代码中的执行顺序一致。（线程内表现为串行的语义）。但被volatile修饰的变量，可以保证该变量赋值的顺序与程序代码中的执行顺序一致。

  ```
  //
  volatile boolean isInitialized = false;
  //
  //假设以下代码在线程A中执行
  void initial(){
    //此处是加载配置文件的代码
    isInitialized = true;
  }
  //
  //假设以下代码在线程B中执行，此方法依赖线程A中加载完配置文件
  void doWork(){
    while (isInitialized){
        //do something 
    }
  }
  ```

  如果变量`isInitialized`没有`volatile`修饰，有可能线程A中的`initial()`方法会先执行`isInitialized = true;`，再执行加载配置文件的代码，就会导致线程B在执行`doWork()`方法的时候报错。

## 先行发生原则

* **概念**\
  先行发生（happens-before）是Java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B（发生在操作B之前），那么操作A产生的影响能被B观察到。这里的影响包括：修改了内存中的共享变量的值、发送了消息、调用了方法等。
* **天然的先行发生关系**
  * **程序次序规则**：在同一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。
  * **管程锁定规则**：一个unlock操作先行发生于后面对于同一个锁的lock操作。这里的后面，是指时间上的先后顺序。
  * **volatile变量规则**：对一个volatile变量的写操作先行发生于后面对这个变量的读操作。这里的后面，是指时间上的先后顺序。
  * **线程启动规则**：Thread对象的start()方法先行发生于此线程的每一个动作。
  * **线程终止规则**：线程中的所有操作都先行发生于对此线程的终止检测，比如可以通过Thread.join()方法、Thread.isAlive()方法的返回值等手段检测到线程已经终止。
  * **线程中断规则**：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。可以通过Thread.interrupted()方法检测到是否有中断发生。
  * **对象终结规则**：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。
  * **传递性**：如果A先行发生于B，B先行发生于C，那么A先行发生于C。

注意：一个操作时间上的先发生不代表这个操作会先行发生，同样，一个先行发生的操作不代表时间上的先发生（指令重排序等）。

```
public class HappensBefore {

    private int value = 0;

    public int getValue() {
        return value;
    }

    public void setValue(int value) {
        this.value = value;
    }
}
```

上述代码中，如果线程A先（时间上的先）调用了`setValue(1)`方法，线程B后（时间上的后）调用了`getValue()`，那么B有可能获取的`value`值是0，而不一定是1。

内容摘抄自《深入理解Java虚拟机》


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://maxwell.gitbook.io/way-to-architect/java-yu-yan/jvm/java-nei-cun-mo-xing.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.