如果你细心观察的话，你会发现，不管是哪一门编程语言，并发类的知识都是在高级篇里。换句话说，这块知识点其实对于程序员来说，是比较进阶的知识。

你我都知道，编写正确的并发程序是一件极困难的事情，并发程序的 Bug 往往会诡异地出现，然后又诡异地消失，很难重现，也很难追踪，很多时候都让人很抓狂。但要快速而又精准地解决“并发”类的疑难杂症，你就要理解这件事情的本质，追本溯源，深入分析这些 Bug 的源头在哪里。

那为什么并发编程容易出问题呢？它是怎么出问题的？今天我们就重点聊聊这些 Bug 的源头。

并发程序幕后的故事

CPU、内存、I/O设备都在不断的迭代，但是在快速发展的过程中，有一个核心矛盾一直存在，就是这三者的速度差异。CPU和内存的速度差异可以形象的描述为：CPU是天上一天，内存是地上一年（假设CPU执行一条普通指令需要一天，那么CPU读写内存得等待一年的时间）。内存和I/O设备的速度差异就更大了，内存是天上一天，I/O设备是地上十年。

为了合理利用CPU的高性能，平衡这三者的速度差异，计算机体系机构、操作系统、编译程序作出了贡献，主要体现为：

1. CPU增加了缓存，以均衡与内存的速度差异；

2. 操作系统增加了进程、线程，以分时复用CPU，进而均衡CPU与I/O设备的速度差异；

3. 编译程序优化指令次序，使得缓存能够得到更加合理地利用

我们在享受这些成果的同时，并发程序很多诡异的问题的根源也在这里

源头之一：缓存导致可见行问题

在单核时代，所有的线程都是在一颗CPU上执行，CPU缓存与内存的数据一致性容易解决。因为所有的线程都是操作同一个CPU的缓存，一个线程对缓存的写，对另一个线程来说一定是可见的。

如图，线程A和线程B都是操作同一个CPU里面的缓存，所以线程A更新了变了V的值，那么线程B之后在访问，得到的一定是最新值（线程A写过的值）。

一个线程对共享变量的修改，另一个线程能够立刻看到，我们称为可见行。

多核时代，每颗CPU都有自己的缓存，这时CPU的缓存与内存的数据一致性就没有那么容易解决了，当多个线程在不同的CPU上执行时，这些线程操作的是不同的CPU缓存。

如图，线程A操作的是CPU-1上的缓存，而线程B操作的是CPU-2上的缓存，很明显这个时候线程A对变量V的操作对于线程B而言就不具备可见行了。

public class Test {
  private long count = 0;
  private void add10K() {
    int idx = 0;
    while(idx++ < 10000) {
      count += 1;
    }
  }
  public static long calc() {
    final Test test = new Test();
    // 创建两个线程，执行 add() 操作
    Thread th1 = new Thread(()->{
      test.add10K();
    });
    Thread th2 = new Thread(()->{
      test.add10K();
    });
    // 启动两个线程
    th1.start();
    th2.start();
    // 等待两个线程执行结束
    th1.join();
    th2.join();
    return count;
  }
}

如上面程序，直觉告诉我们应该是20000，因为在单线程里调用两次add1OK()方法，但实际的结果是10000-20000之间的随机数。为什么呢？

如图，我们假设线程AB同时执行，第一次都会将count=0读到各自的CPU缓存里，执行完count+=1之后，各自CPU缓存里的值都是1，同时写入内存后，我们发现内存中是1，而不是我们期待的2，之后由于各自的CPU缓存里都有了count的值，两个线程都是基于CPU缓存里的count值来计算，所以最终count的值是小于20000的。这就是缓存的可见行问题。

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

由于IO太慢，操作系统发明了多进程和后来的多线程，因此在单核的CPU上我们也可以一遍听着歌，一遍谢Bug，这就是多进程多线程的功劳。

操作系统允许某个进程执行一小段实际，例如50毫秒，过了50毫秒操作系统就会重新选择一个进程来执行（我们称为任务切换，也就是线程切换），这个50毫秒称为“时间片“。

java并发程序都是基于多线程的，自然也就会涉及到任务切换，任务切换的时机大多数都是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里的一条语句往往需要多条CPU指令完成，如count += 1，至少需要三条CPU指令。

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

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

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

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

我们潜意识觉得count +=1这个操作是一个不可分割的整体，就像原子一样，线程的切换可以在count +=1之前，或之后，但是就不会发生在中间。我们把一个或多个操作在CPU执行过程中不被中断的特性称为原子性。CPU能保证的原子操作是CPU指令级别的，而不是高级语言级别的。因此我们很多时候需要在高级语言层面保证操作的原子性。

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

有序性是指程序按照带吗的先后次序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，如“a = 6; b=7"，编译器优化后可能编程“b = 7; a = 6"，该调整不影响程序的最终结果，不过有时候编译器及解释器的优化可能导致意想不到的Bug。

在Java领域一个经典的案例就是利用双重检查创建单例对象。

public class Singleton {
  static Singleton instance; // volatile 可以解决可见性和有序性问题
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

假设有两个线程A、B同时调用getInstance()方法，他们会同时发现instance == null，于是同时对Singleton.class加锁，此时JVM保证只有一个线程加锁成功（假设线程A），线程B处于等待状态；线程A创建一个实例，之后释放锁，线程B被唤醒，加锁，检查instance == null时，发现实例已创建。

这看上去一切很完美，但实际上并不完美，问题出现在new操作上，我们以为的new操作应该是：

1. 分配一块内存M；

2. 在内存M上初始化Singleton对象；

3. 然后M的地址赋值给instance变量

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

1. 分配一块内存M；

2. 将M的地址赋值为instance变量；

3. 最后在内存M上初始化Singleton对象。

优化后导致的问题是：我们假设线程A先执行了getInstance()方法，当执行到指令2时，发生了线程切换，此时线程B也执行了getInstance()方法，那么线程B发现insurance != null，所以直接返回instance，而此时instance是没有初始化的，如果我们访问instance的成员变量就可能发生空指针异常

总结

要写好并发程序，首先要知道并发程序的问题在哪里，问题的深究不外乎就是直觉欺骗了我们，只要我们能够深刻理解可见性、原子性、有序性在并发场景下的原理，很多并发Bug都是可以理解、可以诊断的。

思考

常听人说，在 32 位的机器上对 long 型变量进行加减操作存在并发隐患，到底是不是这样呢？现在相信你一定能分析出来。

公众号 架构道与术(ToBeArchitecturer)，欢迎关注、学习更多干货~