Java并发编程之Java内存模型(JMM)

什么是Java内存模型

什么是Java内存模型（Java Memory Model，JMM）呢？Java内存模型是Java虚拟机规范定义的一种模型，操作系统不是有自己的内存模型吗，为什么Java虚拟机规范还要在操作系统之上再封装一个Java内存模型呢？是这样的，每个操作系统的内存模型都存在一定的差异，像c/c++这类语言就是直接使用操作系统的内存模型，那么就会存在同一套代码，在这个平台运行是没有问题的，换个平台运行就会出现一些问题，而Java语言作为一门跨平台的语言（一次编译，到处运行），自然得屏蔽掉底层不同操作系统内存访问的差异。Java内存模型是Java虚拟机规范定义的用来屏蔽不同操作系统内存访问差异的一种模型

JMM需要保证的3个特性

1. 原子性：Java内存模型直接提供的原子性操作包括read，load，assign，use，store，write，我们可以大致认为Java中对基本类型的访问读写是原子性的（double和long除外），更大范围的原子性有monitorenter和monitorexit（映射到Java代码就是synchornized关键字）指令来保证，同时jdk1.5提供的concurrent包下也有很多保证原子性语义的类。
2. 可见性：可见性是指一个线程修改了某个变量，其他线程能够立即看到这个修改。
   Java内存模型通过变量修改后回写到主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量和volatile的区别在于，volatile的特殊规则保证了修改volatile变量后马上对其他cpu可见，读取volatile变量读最新值。因此，volatile保证了可见性，而普通变量没有
   值的一提的是，除了volatile保证了可见性，synchornized和final也保证了可见性。synchornized要求在unlock之前必须把修改的变量同步回主内存（store,write），因此保证了可见性，而final的内存语义是，一个final修饰的变量在构造器中初始化和将“this”return出去之前不会发生重排序，因此保证了可见性。
3. 有序性：volatile的语义之一就是禁止指令重排序，因此保证了有序性，而synchornized则是由“一个变量在同一个时刻只能有一个线程进行lock”的规则保证有序性的。

主内存和工作内存

Java内存模型中的主内存和物理内存的主内存很相似，但是Java内存模型的主内存仅仅是虚拟内存的一部分，而Java内存模型的工作内存和处理器的高速缓存也很类似，但是需要注意，仅仅是相似，本质是不一样的。那么主内存和工作内存到底是什么呢，它们之间的关系是怎么样的呢？Java中的共享变量必须“诞生”于主内存，如果要从jvm内存结构来看的话，堆就是主内存的一部分，主内存时所有线程共享的，其存储的就是共享变量，而工作内存是每个线程私有的，工作内存里面存储的是对主内存共享变量的副本，简单来说，工作内存就是把主内存的变量拷贝过来。下面是主内存，工作内存以及线程之间的关系：

内存间的交互

如何把一个变量从主内存拷贝到工作内存，还有如何把一个变量从工作内存同步回主内存，Java内存模型定义了以下8种操作来实现，虚拟机的实现必须保证每种操作都是原子性的。

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

如果要把一个变量从主内存复制到工作内存，那么就要顺序执行read和load操作，如果要把变量从工作内存同步回主内存，那么就要顺序执行store和write操作。Java内存模型只要求上述2个操作必须顺序执行，而没有明确要求需要连续执行，也就是说read和load，store和write之间是可以插入其他指令的。除此之外，Java内存模型还规定了在执行上述8中基本操作时必须满足以下规则：

• 不允许read和load，store和write单独出现，即不能出现主内存读取了工作内存不接受，或者工作内存回写了但是主内存不接受的情况
• 不允许线程丢弃最近的assign操作，即线程修改了变量必须回写到主内存
• 不允许一个线程无原因（没有发生assign操作）把工作内存的变量同步回主内存
• 一个新的变量只能诞生于主内存，不允许在工作内存中使用一个未被初始化（load或assign）的变量，换句话说，对一个变量进行use，store之前，必须先执行了assign和load操作
• 一个变量在同一时刻只允许被一个线程lock，但一个线程可以对同一个变量执行多次lock，但是unlock时也需要多次
• 在一个线程使用lock一个变量时，会清空变量在该线程的工作内存的值，在使用前必须先执行load或者assign对变量初始化
• 如果一个线程没有执行lock变量的操作，那么不允许执行unlock
• 执行unlock操作之前，必须把变量同步回主内存（store，write）

这8种内存操作以及上述规则限定，再加上volatile的一些特殊规定，基本上可以确定Java中哪些内存操作在并发下是安全的

指令重排序

为了提高程序的性能，编译器和处理器往往会对指令进行重排序。重排序分为以下3类：

1. 编译器优化的指令重排序
2. 指令并行重排序（指令并行技术，当不存在数据依赖性时，处理器可以修改机器码指令的执行顺序）
3. 内存系统的重排序

如下图：

对于编译器重排序，jmm的编译器重排序规则会禁止特定类型的编译器重排序
对于处理器重排序，jmm的处理器重排序规则要求Java编译器插入一些特定的内存屏障，防止处理器重排序

jmm的内存屏障

Java内存模型定义了以下4中内存屏障类型

1. LoadLoad Barriers：保证LoadLoad Barriers之前的加载动作不会和LoadLoad Barriers之后的动作不会发生重排序，例如 load1;LoadLoad;load2，load1和load2动作不会发生重排序
2. StoreStore Barriers：保证StoreStore Barriers之前的存储动作不会和StoreStore Barriers之后的存储动作重排序，例如store1;StoreStore;store2，store1和store2不会发生重排序
3. LoadStore Barrriers：确保 LoadStore Barrriers之前的load动作不会和 LoadStore Barrriers之后的store动作重排序，例如 load; LoadStore;store，load和store不会重排序
4. StoreLoad Barriers：确保StoreLoad Barriers之前的store动作不会和StoreLoad Barriers之后的load动作重排序，例如store;StoreLoad;load，store和load动作不会发生重排序

as-if-serial

as-if-serial保证了单线程执行，不管如何重排序，最终的执行结果是一致的，因此编译器和处理器不会对存在数据依赖的执行进行重排序。

  public void  method1(){
    int a = 5; // 1
    int b = 6; // 2
  }
  // method1的动作1和动作2由于不存在数据依赖性，因此是可以重排序的
  public void method2(){
    int a = 5; // 1
    int b = a; // 2
  }
  // method2的动作2依赖于动作1，因此不会发生重排序

指的注意的是，as-if-serial仅仅适用于单线程，如果是多线程，那么就需要使用下面的happens-before原则来作为判断依据了

happens-before

happens-before，也就是“先行发生原则”，它是Java里面一个非常重要的原则，它是用来判断是否有数据竞争，线程是否安全的依据。A happens-before B，指的是发生B操作之前，能看到A操作的影响，这里说的影响有很多，比如修改共享变量的值，发送了消息，调用了方法
下面是Java的一些“天然的”先行发生原则。

• 程序次序规则：在一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
• 管程锁定规则：一个对锁的unlock操作先行发生于后面对这个锁lock操作
• volatile变量规则：一个volatile的写操作先行发生于后面对这个volatile变量的读操作
• 线程启动规则：thread.start()操作先行发生于线程的每一个操作
• 线程终止规则：线程的所有操作先行发生于线程的终止操作
• 线程中断规则：对interrupt方法的调用先行发生于被中断线程的代码检测到中断事件的发生
• 对象终结规则：对象的初始化先行发生于对象的finalize方法
• 传递性：如果A操作先行发生于B操作，B操作先行发生于C操作，那么可以得出，A操作先行发生于C操作

volatile

volatile可以说是Java里最轻量级的同步机制了，同时volatile的性能是远远高于synchornized的，但是相对于普通变量，由于编译器会对volatile插入一些内存屏障，所以volatile变量的性能不如普通变量。对volatile修饰的变量和普通变量操作都是一样的（上述8种基本操作），但是Java内存模型对volatile加了一些特殊的规则，以用来保证可见性（一个线程修改了volatile修饰的变量，其他线程是立即可见的），而其实现原理就是volatile修饰的变量经过编译器特殊处理后，不会存储在寄存器，然后通过内存屏障保证volatile的读写不会重排序。
下面我们来看看jmm对变量读写的重排序规则

	第二个操作	第二个操作	第二个操作
第一个操作	普通读写	volatile读	volatile写
普通读写			NO
volatile读	NO	NO	NO
volatile写		NO	NO

从上表我们可以得出以下结论：

• 当操作为volatile写时，volatile写之前的任何操作都不能与volatile写重排序，volatile写之后的volatile读/写不能与volatile写重排序
• 当操作为volatile读时，volatile读之前的volatile读/写不能和volatile读重排序，volatile读之后的所有操作不能与volatile读重排序

让我们来总结下volatile的内存语义：

1. volatile具有可见性，当对volatile变量修改时，其他线程能够立马看见这个修改
2. volatile变量的读写具有原子性，当然像i++这种操作是不具备原子性的

final

其实jdk1.5之前的final是有bug的，就比如说string，因为string对象本身是个final char[]，jdk1.5以前，final的内存语义并没有那么强，当一个线程new String时，还没有对final进行初始化，此时string的this引用还有可能发生逃逸（指令重排序原因），因此很有可能看到一个没有正确初始化的string对象，但是1.5之后并不存在这个问题，因为jdk1.5(jsr-133)对final语义进行了增强，在构造器里会对final字段初始化指令和return this之前加上内存屏障，保证在return this的时候，final变量是正确初始化的。final变量对于所有线程而言，都是可见的，保证了可见性

synchronized和JMM

synchronized具体我就不在这篇文章讲了，这里只介绍synchronized是如何保证JMM的3大特征的，synchronized同时保证了原子性，可见性，有序性，保证原子性很容易理解，因为任意时刻，只有一个线程在执行临界区代码，而可见性的保证是java虚拟机实现的，也就是在unlock时会把所有写操作回写到主内存，至于有序性，synchornized则是由“一个变量在同一个时刻只能有一个线程进行lock”的规则保证有序性的