并发编程(二) - JMM(java内存模型)

迷南。 2023-01-05 14:24 251阅读 0赞

java线程间的通信对程序员完全透明，内存可见性问题很容易困扰Java程序员.

# 1. 并发编程的关键问题 #

在并发编程中，需要处理两个关键问题: **线程之间如何通信**及线程之间如何**同步**?   线程之间通信机制有两种： **共享内存、消息传递**。

## 1.1. `通信`是指线程之间以何种机制来`交换信息` ##

### 1.1.1 共享内存的通信机制 ###

**在共享内存的并发模型里， 线程之间共享程序的公共状态,通过写-读内存中的公共状态进行隐式通信**。

### 1.1.2 消息传递的通信机制 ###

**在消息传递的并发模型里，线程之间没用公共状态，线程之间必须通过发送消息来显示进行通信**。

## 1.2 同步是指程序中用于`控制不同线程间操作发生相对顺序的机制` ##

*  在共享内存并发模型里，同步是显式进行的。程序员必须显示指定某个方法或某段代码需要在线程之间互斥执行。
 *  在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

Java的并发采用的是**共享内存模型**，Java线程之间的通信总是显性进行.

# 2. JMM: java内存模型 #

前面讲到的java并发的共享内存模型称为JMM,在java语言规范(JSR133)中提出.  为什么要制定这个规范呢? 因为在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，但是换了个系统就出现各种问题。Java内存模型，就是为了屏蔽系统和硬件的差异，让一套代码在不同平台下能到达相同的访问结果。JMM从java 5开始的JSR-133发布后，已经成熟和完善起来。

** 在java中 ,所有的实例域，静态域和数组元素都存储在堆内存中，堆内存在线程之间共享**。局部变量, 方法定义参数和异常处理器参数不会在线程之间共享，它们没有内存可见性问题，也不受内存模型的影响.

JMM规定了内存主要划分为**主内存**和**工作内存**两种。此处的主内存和工作内存跟JVM内存划分（堆、栈、方法区）是在不同的层次上进行的，如果非要对应起来，主内存对应的是Java堆中的对象实例部分，工作内存对应的是栈中的部分区域，从更底层的来说，主内存对应的是硬件的物理内存，工作内存对应的是寄存器和高速缓存。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70][]

JVM在设计时候考虑到，如果JAVA线程每次读取和写入变量都直接操作主内存，对性能影响比较大，所以每条线程拥有各自的工作内存，工作内存中的变量是主内存中的一份拷贝，线程对变量的读取和写入，直接在工作内存中操作，而不能直接去操作主内存中的变量。但是这样就会出现一个问题，当一个线程修改了自己工作内存中变量，对其他线程是不可见的，会导致线程不安全的问题。因为JMM制定了一套标准来保证开发者在编写多线程程序的时候，能够控制什么时候内存会被同步给其他线程。

## 2.1 内存交互操作 ##

内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许例外）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1][]

以上八种操作定义如下:

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

JMM对这八种指令的使用，制定了如下规则：

*  不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
 *  不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
 *  不允许一个线程将没有assign的数据从工作内存同步回主内存
 *  一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前，必须经过assign和load操作
 *  一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
 *  如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
 *  如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
 *  对一个变量进行unlock操作之前，必须把此变量同步回主内存  
      
    JMM对这八种操作规则和对[volatile的一些特殊规则][volatile]就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，使用java的**happen-before**规则来进行分析。

## 2.2 操作分析 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 2][]

从上图来看，如线程A要与线程B通信，步骤如下:

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

具体到一次操作来分析:

在本地内存A和B中有主内存中共享变量x的副本。

假设初始时，这三个内存中的x值都为0。线程A在执行时，把更新后的x值（假设值为1）临时存放在自己的本地内存A中。当线程A和线程B需要通信时，线程A首先会把自己本地内存中修改后的x值刷新到主内存中，
    此时主内存中的x值变为了1。随后，线程B到主内存中去读取线程A更新后的x值，此时线程B的本地内存的x值也变为了1。

从整体来看，这两个步骤实质上是线程A在向线程B发送消息，而且这个通信过程必须要经过主内存。

JMM通过控制主内存与每个线程的本地内存之间的交互，来为java程序员提供**内存可见性保证**。

# 3. 为了提升程序性能，从源代码到指令序列的重排序 #

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。

重排序分三种类型：

1，**编译器优化的重排序**。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。  
2，**指令级并行的重排序**。现代处理器采用了指令级并行技术（Instruction-Level Parallelism， ILP）来将多条指令重叠执行。  
   如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。  
3，**内存系统的重排序**。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

从java源代码到最终实际执行的指令序列，会分别经历下面三种重排序：

![20210113112519223.png][]

上述的1属于编译器重排序，2和3属于处理器重排序。

**这些指令重排序都可能会导致多线程程序出现内存可见性问题。**

*  对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。
 *  对于处理器重排序，JMM的处理器重排序规则会要求java编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel称之为memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

**JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。**

# 4. 处理器重排序 #

现代的处理器使用写缓冲区来临时保存要向内存写入的数据。

写缓冲区可以保证指令流水线持续运行，它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟。
    同时，通过以批处理的方式刷新写缓冲区，以及合并写缓冲区中对同一内存地址的多次写，可以减少对内存总线的占用。
    
    虽然写缓冲区有这么多好处，但每个处理器上的写缓冲区，仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响：   处理器对内存的读/写操作的执行顺序，不一定与内存实际发生的读/写操作顺序一致！

请看以下示例分析:

![20210114084702403.png][]

假设处理器A和处理器B按程序的顺序并行执行内存访问，最终却可能得到x = y = 0的结果.

具体的原因如下分析:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 3][]

在这里，最开始时主内存中保存了共享变量a=b=0的初始状态值，当处理器A,B分别操作 a=1,b=2 这一步时(我们记作 A1,b1 ), 处理器A和处理器B可以同时把共享变量写入自己的写缓冲区, 然后它们的下一条代码(  x=b  和 y=a )实际上由**两次操作**组成，先要完成从主内存中读取另一个变量的过程，对于处理器A而言，此时它要从主内存中读取 b 的值，而对于处理器B而言，它则要从主内存中读取a的值，前面我们说过主内存中保存的是共享变量a=b=0的初始值，这一步我们记作 A2,B2，这样x=y=0了,    另一次操作才是把处理器A,B各自写缓存区中保存的脏数据刷新到内存中（记作A3,B3). 当以上面描述的时序执行时，程序就会得到x=y=0的结果了.

从主内存操作(对于处理器A这一边是A2,A3,处理器B是B2,B3) 实际发生的顺序来看，直到处理器A执行A3来刷新自己的写缓存区，写操作A1才算真正执行了。 虽然处理器A执行内存操作的顺序为：A1->A2，但内存操作实际发生的顺序却是：A2->A1。 此时，处理器A的内存操作顺序被重排序了（处理器B的情况和处理器A一样，这里就不赘述了）。

这里的关键是，由于写缓冲区仅对自己的处理器可见，它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。 **由于现代的处理器都会使用写缓冲区，因此现代的处理器都会允许对写-读操做重排序。**

下面是常见处理器允许的重排序操作类型的列表：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 4][]

以上表格的解读:   上表单元格中的“N”表示处理器不允许两个操作重排序，“Y”表示允许重排序,  最后一列表示待操作的数据如果有依赖关系，则所有的处理器都不允许指令重排序.

**从上表我们可以看出：** **常见的处理器都允许Store-Load重排序；常见的处理器都不允许对存在数据依赖的操作做重排序。 sparc-TSO和x86拥有相对较强的处理器内存模型，它们仅允许对写-读操作做重排序（因为它们都使用了写缓冲区）。 另外ARM处理器的内存架构与PowerPC相似. **

为了保证内存可见性，java编译器在生成指令序列的适当位置会插入**内存屏障指令**来禁止特定类型的处理器重排序。

**JMM把内存屏障指令分为下列四类:**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 5][]

**StoreLoad Barriers**是一个“全能型”的屏障，它同时具有其他三个屏障的效果。

现代的多处理器大都支持该屏障（其他类型的屏障不一定被所有处理器支持）。

执行该屏障开销会很昂贵，因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中（buffer fully flush）。

# 5. happens-before原则 #

从JDK5开始，java使用新的JSR -133内存模型, 它提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。

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

**与程序员密切相关的happens-before规则如下：**

*  **程序顺序规则**： 一个线程中的每个操作，happens- before 于该线程中的任意后续操作。
 *  **监视器锁规则：**对一个监视器锁的解锁，happens- before 于随后对这个监视器锁的加锁。
 *  **volatile变量规则**：对一个volatile域的写，happens- before 于任意后续对这个volatile域的读。
 *  **传递性：** 如果A happens- before B，且B happens- before C，那么A happens- before C。
 *  线程启动规则：在主线程A执行过程中，启动子线程B，那么线程A在启动子线程B之前对共享变量的修改结果对线程B可见。
 *  线程终止规则：在主线程A执行过程中，子线程B终止，那么线程B在终止之前对共享变量的修改结果在线程A中可见。也称线程join()规则。
 *  线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程代码检测到中断事件的发生，可以通过Thread.interrupted()检测到是否发生中断。
 *  对象终结规则：这个也简单的，就是一个对象的初始化的完成，也就是构造函数执行的结束一定 happens-before它的finalize()方法

happens-before仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前（the first is visible to and ordered before the second）.

**happens-before与JMM的关系如下图所示：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 6][]

如上图所示，一个happens-before规则通常对应于多个编译器重排序规则和处理器重排序规则。

对于java程序员来说，happens-before规则简单易懂，它避免程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70]: /images/20221119/02f4b35fffe649d69e23e0adcd427a50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1]: /images/20221119/d7fb7063983f4fce8d004a369a1d4628.png
[volatile]: https://www.cnblogs.com/null-qige/p/8569131.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210113111527817.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[20210113112519223.png]: https://img-blog.csdnimg.cn/20210113112519223.png
[20210114084702403.png]: https://img-blog.csdnimg.cn/20210114084702403.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20210114084904283.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20210114094128636.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20210117104341146.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20210117110040247.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk=,size_16,color_FFFFFF,t_70