并发编程Bug的源头

本文来自《Java并发编程实战》的第一篇《可见性、原子性和有序性问题：并发编程Bug的源头》，主要介绍了并发问题出现的原因。更多文章查看：Java并发学习记录总目录

---

由于为CPU，内存，I/O设备之间的速度差异很大，CPU速度很快，I/O速度很慢。有时候CPU很快处理完某些任务，却因为要等待I/O的完成，CPU就空闲在那，浪费了CPU资源。影响系统的性能，CPU和内存，内存和I/O设备都可能发生这样的事。为了合理利用CPU的高性能，平衡三者的速度差异，计算机体系系统，操作系统，编译程序都做出了贡献，主要体现在。

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

现在我们几乎所有的程序都默默地享受着这些成果，但是天下没有免费的午餐，并发程序很多诡异问题的根源也在这里。

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

CPU将内存中的变量数据保存到CPU的缓存当中，这样减少向内存读取数据，加快了CPU的效率。一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。

在单核的时候，所有线程操作的是一个CPU的缓存，一个CPU队缓存的写，另一个CPU一定是可以立刻看到的。

多核时代，每颗 CPU 都有自己的缓存，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的CPU缓存。例如下图，线程A操作CPU-1上的缓存，线程B操作CPU-2上的缓存。这时，线程A对变量V的操作对于线程B来说是不具备可见性的。这样就会出现缓存不一致问题。

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

由于IO太慢，早期的操作系统发明了多进程，操作系统允许某个进程执行一小段时间（称为“时间片”），时间一到就换一个进程执行（称为“任务切换”）。在一个时间片内，如果一个进程进行一个IO操作（例如将文件读进内存），这是进程可以吧自己的标记为“休眠状态”，让出CPU的使用权，让CPU去处理其他的等IO操作结束，就将这个休眠的进程唤醒，唤醒后的进程就有机会重新获取CPU的使用权了。

这种方式提高了CPU的使用率，现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。任务切换也是并发编程里诡异 Bug 的源头之一。任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条 CPU 指令完成，例如上面代码中的count += 1，至少需要三条 CPU 指令。

指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；

指令 2：之后，在寄存器中执行 +1 操作；

指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

作系统做任务切换，可以发生在任何一条CPU 指令执行完。对于上面的三条指令来说，我们假设 count=0，如果线程 A 在指令 1 执行完后做线程切换，线程 A 和线程 B 按照下图的序列执行，那么我们会发现两个线程都执行了 count+=1 的操作，但是得到的结果不是我们期望的 2，而是 1。

我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符，这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。

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

有序性。顾名思义，有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”在 Java 领域一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例。

public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

这看上去一切都很完美，无懈可击，但实际上这个 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 都是可以理解、可以诊断的。

在介绍可见性、原子性、有序性的时候，特意提到缓存导致的可见性问题，线程切换带来的原子性问题，编译优化带来的有序性问题，其实缓存、线程、编译优化的目的和我们写并发程序的目的是相同的，都是提高程序性能。但是技术在解决一个问题的同时，必然会带来另外一个问题，所以在采用一项技术的同时，一定要清楚它带来的问题是什么，以及如何规避。