本文内容来自 Java并发实战：01 | 可见性、原子性和有序性问题：并发编程Bug的源头

本质

CPU，内存，I/O 三者存在速度差异。
**

  • CPU 增加缓存，以均衡与内存的速度差异
  • 操作系统增加了进程、线程，以 分时复用 CPU，均衡 CPU 与 I/O 设备的速度差异
  • 编译器 优化指令执行次序，使得缓存能够得到更加合理地利用

并发三大问题

源头1：缓存导致的可见性问题

定义：一个线程对共享变量修改，另外一个线程能够立刻看到，我们称为 可见性
**
多核 CPU 都有自己的缓存，线程 A 操作 CPU 1 的缓存，线程 B 操作 CPU 2 的缓存，此时线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。
😺 并发编程出现 bug 的源头 - 图1

源头2：线程切换带来的原子性问题

定义：一个或者多个操作在 CPU 执行的过程中不被中断的特性称为 原子性
**
操作系统允许某个进程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会重新选择一个进程来执行（我们称为「任务切换」），这个 50 毫秒称为「时间片」。

早期的操作系统基于进程来调度 CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量的线程来调度，现在我们提到的「任务切换」都是指「线程切换」。

😺 并发编程出现 bug 的源头 - 图2
操作系统做任务切换，可以发生在任何一条 CPU 指令执行完。是 CPU 指令，而不是高级语言里的一条语句。

例如 count += 1，至少需要三条 CPU 指令

  • 指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器
  • 指令 2：之后，在寄存器中执行 +1 操作
  • 指令 3：最后，将结果写入内存（缓存机制导致可能写入 CPU 缓存而不是内存）


对于上面的三条指令来说，我们假设 count=0，如果线程 A 在指令 1 执行完后做线程切换，线程 A 和线程 B 按照下图的序列执行，那么我们会发现两个线程都执行了 count+=1 的操作，但是得到的结果不是我们期望的 2，而是 1。
😺 并发编程出现 bug 的源头 - 图3
CPU 能保证的原子操作是 CPU 指令级别的**，而不是高级语言的操作符，这是违背我们直觉的地方。

因此，很多时候我们需要 在高级语言层面保证操作的原子性

源头3：编译优化带来的有序性问题

定义：有序性 指程序按照代码的先后顺序执行，但编译器优化可能导致指令重排
**
在 Java 领域一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例。

  1. public class Singleton {
  2.   static Singleton instance;
  3.   static Singleton getInstance(){
  4.     if (instance == null) {
  5.       synchronized(Singleton.class) {
  6.         if (instance == null)
  7.           instance = new Singleton();
  8.         }
  9.     }
  10.     return instance;
  11.   }
  12. }

假设有两个线程 A、B 同时调用 getInstance() 方法，他们会同时发现 instance == null ，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 A），另外一个线程则会处于等待状态（假设是线程 B）；线程 A 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。这看上去一切都很完美，无懈可击，但 实际上这个 getInstance() 方法并不完美。问题出在哪里呢？
出在 new 操作上。
**
我们以为的 new 操作应该是：

  1. 分配一块内存 M
    2. 在内存 M 上初始化 Singleton 对象
    3. 然后 M 的地址赋值给 instance 变量

但是实际上优化后的执行路径却是这样的：

1. 分配一块内存 M
2. 将 M 的地址赋值给 instance 变量
3. 最后在内存 M 上初始化 Singleton 对象

优化后会导致什么问题呢？我们假设线程 A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance() 方法，那么线程 B 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常。

😺 并发编程出现 bug 的源头 - 图4

解决

我们可以根据解产生问题的原因来解决并发的三大问题。

解决可见性和有序性问题

解决可见性和有序性问题，最直接的办法便是 禁用缓存和编译优化。这种方式过于暴力，合理的方案应该是：

按需禁用缓存以及编译优化**

那么，如何做到「按需禁用」呢？对于并发程序，何时禁用缓存以及编译优化只有程序员知道，那所谓「按需禁用」其实就是指按照程序员的要求来禁用。所以，为了解决可见性和有序性问题，只需要提供给程序员按需禁用缓存和编译优化的方法即可。

这便是 Java 内存模型**。**
语雀内容

解决原子性问题

解决原子性问题的 本质 是 保证中间状态对外不可见。即保证 同一时刻只有一个线程执行（互斥）
这便是 **锁**。
语雀内容