深入理解JVM：Java内存模型与线程

概述

衡量一个服务性能的高低好坏，每秒事务处理数（Transactions Per Second，TPS）是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS值与程序的并发能力又有非常密切的关系。

硬件的效率与一致性

1. 硬件的效率问题：

   处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个I/O操作就是很难消除的（无法仅靠寄存器来完成所有运算任务）。

2. 解决：

   高速缓存（Cache），用来作为内存与处理器之间的缓冲；

3. 导致新的问题：

   缓存一致性（Cache Coherence）：每个处理器都有自己的高速缓存，而它们又共享同一主内存（Main Memory），多个处理器任务涉及同一主内存区域时，可能导致各自的缓存数据不一致。

4. 解决：

   各个处理器访问缓存时都遵循一些协议：MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly 及 Dragon Protocol等。

• “内存模型”：可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。

  不同架构的物理机器可以拥有不一样的内存模型，而Java虚拟机也有自己的内存模型；

硬件的内存模型：

   除了增加高速缓存之外，为了使处理器内部的运算单元能尽量被充分利用，处理器可能会对输入代码进行乱序执行（Out-Of-Order Execution）优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中各个语句计算的先后顺序与输入代码中的顺序一致，因此如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能靠代码的先后顺序来保证。

与处理器的乱序执行优化类似，Java虚拟机的即时编译器中也有指令重排序（Instruction Reorder）优化。

Java内存模型（Java Memory Model，JMM）

《Java虚拟机规范》中曾试图定义一种“Java内存模型”[2]（Java Memory Model，JMM）来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。

主内存与工作内存

1. 主内存（Main Memory）：Java内存模型规定了所有的变量都存储在主内存中（仅是虚拟机内存的一部分）；
2. 工作内存（Working Memory）：线程的工作内存中保存了被该线程使用的变量的主内存副本；
   • 每条线程还有自己的工作内存。
   • 线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。
   • 不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

线程、主内存、工作内存三者的交互关系：【与前一节物理机内存模型类比】

内存间交互操作

Java内存模型中定义了以下8种操作来完成：

• Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

  （对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许有例外）

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内存模型还规定了在执行上述8种基本操作时必须满足如下规则：

1. 不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者工作内存发起回写了但主内存不接受的情况出现。
2. 不允许一个线程丢弃它最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
3. 不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
4. 一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作。
5. 一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
6. 如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作以初始化变量的值。
7. 如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
8. 对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

• 这8种内存访问操作以及上述规则限定，再加上稍后会介绍的专门针对volatile的一些特殊规定，就已经能准确地描述出Java程序中哪些内存访问操作在并发下才是安全的。

  （以上操作可以简化为read、write、lock和unlock四种）另一种等效判断原则——“先行发生原则”，亦可用来确定一个操作在并发环境下是否安全的。

对于volatile型变量的特殊规则

• （“volatile可以看作是Java虚拟机提供的最轻量级的同步机制”；）

当一个变量被定义成volatile之后，它将具备两项特性：

1. 保证此变量对所有线程的可见性：“当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。”

   （普通变量的值在线程间传递时均需要通过主内存来完成：线程A修改变量值，回写主内存，线程B读取主内存，新变量值才会对线程B可见）

   • volatile变量在各个线程的工作内存中是不存在一致性问题的；

     （“从物理存储的角度看，各个线程的工作内存中volatile变量也可以存在不一致的情况，但由于每次使用之前都要先刷新，执行引擎看不到不一致的情况，因此可以认为不存在一致性问题”）

   • volatile不能保证变量的运算在并发下是线程安全的；
2. 禁止指令重排序优化：操作volatile变量的指令，其前后操作指令有序【在其前（后）的操作不能重排序到其之后（前），但前后部分内可重排序】
   • 相当于一个内存屏障（Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置）；

• 由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，仍然要通过加锁（使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：
  1. 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
  2. 变量不需要与其他的状态变量共同参与不变约束。

• 利用“volatile”来实现“双锁检测”（Double Check Lock，DCL）的单例代码：

  public class Singleton {
  	private volatile static Singleton instance;
  	public static Singleton getInstance() {
  		if (instance == null) {
  			synchronized (Singleton.class) {
  				if (instance == null) {
  					instance = new Singleton();
  				}
  			}
  		}
  		return instance;
  	}
  	public static void main(String[] args) {
  		Singleton.getInstance();
  	}
  }
  

  编译后，这段代码对instance变量赋值的部分如代码：

  0x01a3de0f: mov			$0x3375cdb0,%esi 		;...beb0cd75 33
  												; {oop('Singleton')}
  0x01a3de14: mov 		%eax,0x150(%esi) 		;...89865001 0000
  0x01a3de1a: shr 		$0x9,%esi 				;...c1ee09
  0x01a3de1d: movb 		$0x0,0x1104800(%esi) 	;...c6860048 100100
  0x01a3de24: lock addl 	$0x0,(%esp) 			;...f0830424 00
  												;*putstatic instance
  												; - Singleton::getInstance@24
  

  通过对比发现，关键变化在于有volatile修饰的变量，赋值后（“mov%eax，0x150(%esi)”便是赋值操作）多执行了一个“lock addl$0x0，(%esp)”操作，这个操作的作用相当于一个内存屏障（指令中的“addl$0x0，(%esp)”即“把ESP寄存器的值加0”是一个空操作）；

  • （只有一个处理器访问内存时，并不需要内存屏障；但如果有两个或更多处理器访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。）

volatile的使用：

• volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。
• volatile与锁中选择的唯一判断依据仅仅是volatile的语义能否满足使用场景的需求。

Java内存模型中对volatile变量定义的特殊规则的定义：
（假定T表示一个线程，V和W分别表示两个volatile型变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：）

   只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作；
   并且，只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load动作。
   线程T对变量V的use动作可以认为是和线程T对变量V的load、read动作相关联的，必须连续且一起出现。

• 每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改。【可见性（读）】

   只有当线程T对变量V执行的前一个动作是assign的时候，线程T才能对变量V执行store动作；
   并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign动作。
   线程T对变量V的assign动作可以认为是和线程T对变量V的store、write动作相关联的，必须连续且一起出现。

• 每次修改V后都必须立刻同步回主内存中，用于保证其他线程可以看到自己对变量V所做的修改。【可见性（写）】

   假定动作A是线程T对变量V实施的use或assign动作，假定动作F是和动作A相关联的load或store动作，假定动作P是和动作F相应的对变量V的read或write动作；
   与此类似，假定动作B是线程T对变量W实施的use或assign动作，假定动作G是和动作B相关联的load或store动作，假定动作Q是和动作G相应的对变量W的read或write动作。
   如果A先于B，那么P先于Q。

• 求volatile修饰的变量不会被指令重排序优化，从而保证代码的执行顺序与程序的顺序相同。【禁止指令重排序】

针对long和double型变量的特殊规则

   Java内存模型要求lock、unlock、read、load、assign、use、store、write这八种操作都具有原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现自行选择是否要保证64位数据类型的load、store、read和write这四个操作的原子性，这就是所谓的“long和double的非原子性协定”（Non-Atomic Treatment of double and long Variables）。

• 目前主流平台下商用的64位Java虚拟机中并不会出现非原子性访问行为，但是对于32位的Java虚拟机，譬如比较常用的32位x86平台下的HotSpot虚拟机，对long类型的数据确实存在非原子性访问的风险。

  从JDK 9起，HotSpot增加了一个实验性的参数“-XX：+AlwaysAtomicAccesses”来约束虚拟机对所有数据类型进行原子性的访问。

• 在实际开发中，除非该数据有明确可知的线程竞争，否则不需要因为这个原因刻意把用到的long和double变量专门声明为volatile。

Java与协程

12.5.1　内核线程的局限 12.5.2　协程的复苏 12.5.3　Java的解决方案