并发可见性、有序性、原子性与JMM内存模型深入解析

叁歲伎倆 2023-10-13 11:48 14阅读 0赞

# 并发三大特性 #

## 原子性 ##

一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在 Java 中，对基本数据类型的变量的读取和赋值操作是原子性操作（64位处理器）。不采取任何的原子性保障措施的自增操作并不是原子性的，比如i++操作。

java复制代码for (int i = 0; i < 10; i++) {
       Thread thread = new Thread(() -> {
          for (int j = 0; j < 10000; j++) {
             counter++;
          }
    
       });
       thread.start();
    }

上面这段代码就存在线程安全问题，因为counter++并不是一个原子操作。

如何保证原子性

*  通过 synchronized 关键字保证原子性
 *  通过 Lock锁保证原子性
 *  通过 CAS保证原子性

## 可见性 ##

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。

下面是模拟两个线程对共享变量操作的例子，用来分析线程间的可见性问题。

java复制代码public class VisibilityTest {
       private boolean flag = true;
    
       public void refresh() {
          // 希望结束数据加载工作
          flag = false;
          System.out.println(Thread.currentThread().getName() + "修改flag:" + flag);
       }
    
       public void load() {
          System.out.println(Thread.currentThread().getName() + "开始执行.....");
          while (flag) {
             //TODO  业务逻辑：加载数据
          }
          System.out.println(Thread.currentThread().getName() + "数据加载完成，跳出循环");
       }
    
       public static void main(String[] args) throws InterruptedException {
          VisibilityTest test = new VisibilityTest();
          // 线程threadA模拟数据加载场景
          Thread threadA = new Thread(() -> test.load(), "threadA");
          threadA.start();
          // 让threadA先执行一会儿后再启动线程B
          Thread.sleep(1000);
          // 线程threadB通过修改flag控制threadA的执行时间，数据加载可以结束了
          Thread threadB = new Thread(() -> test.refresh(), "threadB");
          threadB.start();
       }
    }

运行结果：threadA没有跳出循环，也就是说threadB对共享变量flag的更新操作对threadA不可见，存在可见性问题。

为什么会有可见性问题呢？这就跟JMM模型有关系，后面内容会详细分析。

**如何保证可见性？**

>  *  通过 volatile 关键字保证可见性
>  *  通过 内存屏障保证可见性（Thread.sleep()能保证可见性就是方法里使用了内存屏障）
>  *  通过 synchronized 关键字保证可见性
>  *  通过 Lock锁保证可见性

## 有序性 ##

即程序执行的顺序按照代码的先后顺序执行。为了提升性能，编译器和处理器常常会对指令做重排序，**编译器的指令重排只能保证单线程下的正确性，但是并不能保证多线程下的正确性。** 也就是存在有序性问题。 举个简单的例子，看下面这段代码：

java复制代码int i = 0;              
    boolean flag = false;
    i = 1;                //语句1  
    flag = true;          //语句2

上面代码定义了一个int型变量，定义了一个boolean类型变量，然后分别对两个变量进行赋值操作。从代码顺序上看，语句1是在语句2前面的，那么JVM在真正执行这段代码的时候会保证语句1一定会在语句2前面执行吗? 不一定，为什么呢? 这里可能会发生指令重排序（Instruction Reorder）。

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

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

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

![format_png][]

上述的 1 属于编译器重排序，2 和 3 属于处理器重排序。这些重排序都可能会导致多线程程序出现内存可见性问题。对于编译器，JMM 的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。对于处理器重排序，JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时，插入特定类型的内存屏障（memory barriers，intel 称之为 memory fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序（不是所有的处理器重排序都要禁止）。

**如何保证有序性？**

>  *  通过 volatile 关键字保证有序性
>  *  通过 内存屏障保证有序性
>  *  通过 synchronized关键字保证有序性
>  *  通过Lock锁保证有序性

## 总结 ##

*  CPU 增加了缓存，以均衡与内存的速度差异；// 导致 `可见性`问题
 *  操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；// 导致 `原子性`问题
 *  编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。// 导致 `有序性`问题

# Java内存模型的抽象结构 #

Java线程之间的通信由Java内存模型（Java Memory Model，简称JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存中，每个线程都有一个私有的本地内存，本地内存中存储了共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在，它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。

根据JMM的规定，线程对共享变量的所有操作都必须在自己的本地内存中进行，不能直接从主内存中读取。

![format_png 1][]

从上图看，线程A和线程B之间要通信的话，必须经历以下两个步骤：

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

所以，线程A无法直接访问线程B的工作内存，线程间通信必须经过主内存。**JMM通过控制主内存与每个线程的本地内存之间的交互，来为Java程序提供内存可见性的保证。**

## 主内存与工作内存交互协议 ##

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了以下八种原子操作来完成：

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

![format_png 2][]

Java内存模型还规定了在执行上述八种基本操作时，必须满足如下规则：

*  如果要把一个变量从主内存中复制到工作内存，就需要按顺序地执行read和load操作， 如果把变量从工作内存中同步回主内存中，就要按顺序地执行store和write操作。**但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。**
 *  不允许read和load、store和write操作之一单独出现
 *  不允许一个线程丢弃它的最近assign的操作，即**变量在工作内存中改变了之后必须同步到主内存中。**
 *  不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
 *  一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量。即就是对一个变量实施use和store操作之前，必须先执行过了assign和load操作。
 *  一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock和unlock必须成对出现
 *  **如果对一个变量执行lock操作，将会清空工作内存中此变量的值**，在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
 *  如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作；也不允许去unlock一个被其他线程锁定的变量。
 *  **对一个变量执行unlock操作之前，必须先把此变量同步到主内存中（执行store和write操作）。**

## 可见性案例深入分析 ##

![format_png 3][]

Java中可见性底层有两种实现：

1.  内存屏障 （synchronized Threed.sleep(10) volatile)

lock addl $0x0,(%rsp)

1.  cup上下文切换 （Threed.yield() Threed.sleep(0) ）

## 锁的内存语义 ##

锁获取和释放的内存语义：

*  当线程获取锁时，JMM会把该线程对应的本地内存置为无效。
 *  当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。

synchronized关键字的作用是确保多个线程访问共享资源时的互斥性和可见性。在获取锁之前，线程会将共享变量的最新值从主内存中读取到线程本地的缓存中，释放锁时会将修改后的共享变量的值刷新到主内存中，以保证可见性。

## volatile内存语义 ##

volatile写的内存语义：

**当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。**

volatile读的内存语义：

**当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。**

### volatile内存语义的实现原理 ###

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

### volatile禁止重排序规则 ###

为了实现volatile的内存语义，JMM会限制编译器重排序，JMM针对编译器制定了volatile重排序规则表。

![format_png 4][]

由表中可以看出，volatile禁止重排序场景：

1. 当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。

2. 当第一个操作是volatile读时，不管第二个操作是什么，都不能重排序。

3. 当第一个操作是volatile写，第二个操作是volatile读时，不能重排序。

[format_png]: https://img-blog.csdnimg.cn/img_convert/a0d417a03c139f527ad9601874290fbb.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/6eed9c0f3879caa8c8058a3b3850dd60.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/1588161b66e916a2f103794ffe82964b.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/f513ac7b67bcd19574bc643bcc1a4275.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/4eb14189d1b8808adb7b508bdb7f125f.webp?x-oss-process=image/format,png