如果你细心的话，就会发现，不论哪一门语言，并发类都是在高级篇里，换句话说，这块知识点对于程序员来说是比较进阶的知识，比如你对操作系统的知识一无所知的话，那去理解一些原理就比较费力气。

编发编程是一件很困难的事情，并发程序的bug往往很诡异，让人很抓狂，快速精准的解决需要穷本溯源。

并发程序幕后的故事

这些年，我们的 CPU、内存、I/O 设备都在不断迭代，不断朝着更快方向努力，在这个过程中，有一个核心矛盾一直存在。就是三者之间额差异，CPU和内存的速度可以描述为：CPU是天上一天，内存是地上一年，（CPU执行普通指令与读写内存等待时间内存和 I/O 设备的速度差异就更大了，内存是天上一天，I/O 设备是地上十年。

程序里大部分程序都要访问内存，有些还要访问IO，根据木桶理论，程序的整体性能取决于最慢的读写IO设备，也就是单方面提高CPU性能是无效的。

为了合理利用CPU的性能，平衡三者之间的差异，计算机体系结构，操作系统，编译程序都做了贡献，主要体现为：

1. CPU增加了缓存，以平衡与内存的差异
2. 操作系统增加了进程、线程以分时复用CPU，进而均衡CPU与IO设备的速度差异
3. 编译程序优化指令执行顺序，使得缓存更加合理利用

我们都默默享受这些成果，但是并发问题的很多根源也来自于这里。

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

在单核时代，所有线程都是在一颗CPU上面运行，CPU缓存与数据一致性很容易解决，因为所有的线程都是操作同一个CPU缓存，一个线程对缓存的读写对另外线程来说是可见的。如下图：

线程 A对数据的变更对于线程B是可见的。这个我们成为可见性

多核时代，每个CPU都有自己的缓存，这个时候CPU的缓存与内存的数据一致性就没有那么容易解决了。当多个线程在不同的CPU 上执行时，这些线程操作的时不同的CPU 缓存，比如下图中 线程 A 操作的是 CPU-1 上的缓存，而线程 B 操作的是 CPU-2 上的缓存，很明显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。这个就属于硬件程序员给软件程序员挖的“坑”。

下面我们再用一段代码来验证一下多核场景下的可见性问题。下面的代码，每执行一次 add10K() 方法，都会循环 10000 次 count+=1 操作。在 calc() 方法中我们创建了两个线程，每个线程调用一次 add10K() 方法，我们来想一想执行 calc() 方法得到的结果应该是多少呢？

当只有一个线程调用的时候

public class CounterTest {

    private int count = 0;

    private void add10k() {
        for (int idx = 0; idx < 10000; idx++) {
            count += 1;
        }
    }

    public static void main(String[] args) {

        CounterTest test = new CounterTest();
        //当只有一个线程调用时，输出结果
        new Thread(() -> {
            test.add10k();
            System.out.println(test.count);
        }).start();

        System.out.println("main thread is over");
    }
}

输出结果：
main thread is over
10000

增加一个线程：

public class CounterTest {

    private int count = 0;

    private void add10k() {
        for (int idx = 0; idx < 10000; idx++) {
            count += 1;
        }
    }

    public static void main(String[] args) throws Exception {

        CounterTest test = new CounterTest();
        //当只有一个线程调用时，输出结果
        Thread t1 = new Thread(() -> {
            test.add10k();
            System.out.println(test.count);
        });

        //增加一个线程
        Thread t2 = new Thread(() -> {
            test.add10k();
            System.out.println(test.count);
        });

        t1.start();
        t2.start();

        t1.join();
        t2.join();

        System.out.println("main thread is over");
    }
}

输出结果：
11827
19664
main thread is over

直觉告诉我们应该是 20000，因为在单线程里调用两次 add10K() 方法，count 的值就是 20000，但实际上 calc() 的执行结果是个 10000 到 20000 之间的随机数。为什么呢？

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

循环 10000 次 count+=1 操作如果改为循环 1 亿次，你会发现效果更明显，最终 count 的值接近 1 亿，而不是 2 亿。如果循环 10000 次，count 的值接近 20000，原因是两个线程不是同时启动的，有一个时差。

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

由于IO太慢，早起的操作系统就发明了多线程，即便在单核的CPU 上，我们也可以一边听歌，一边写BUG，这个就是多进程的功劳。

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

在一个时间片里，如果一个进程进行IO操作，例如读某个文件，这个时候该进程可以标记自己为休眠状态，并让渡CPU的使用权，待文件读进内存，操作系统唤醒该进程，该进程就有机会再次获取CPU的使用权了。

这里的进程在等待IO时之所以会释放CPU 的使用权，是为了让CPU 在这段时间可以做别的事情，这样一来CPU 的使用率就上来了；此外，如果这时也有另外一个进程也读文件，读文件的操作就会排队，磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样IO的使用率就上来了。

是不是很简单的逻辑？但是，虽然看似简单，支持多进程分时复用在操作系统的发展史上却有里程碑的意义，Unix 就是因为解决了这个问题而名震天下。

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

Java并发编程都是基于线程的，自然设计任务的切换，所以任务切换竟然是并发编程的bug源头之一，任务切换的时机大多是在时间片结束的时候，我们现在基本使用的高级语言，高级语言里，一条语句往往需要多条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 之前，也可以发生在count+=1 之后，但就是不会发生在中间，我们把一个或者多个操作在CPU 执行的过程中不被中断的特性成为原子性。CPU 能保证的原子操作是CPU 指令级别的，而不是高级语言的操作符。这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。

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

那么并发编程有没有其他容易导致bug技术呢？有，有序性，顾名思义，就是代码执行的顺序，编译器为了优化性能，有时候会改变代码的语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”， 在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。有时候编译器及解释器的优化可能导致意想不到的Bug 。

在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;
  }
}

假设有两个线程 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 变量。

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

总结

要写好并发程序，首先要知道并发程序的问题在哪里，只有确定了靶子，才能有的放矢，只要我们深刻理解了可见性、原子性、有序性在并发场景下的梳理，很多并发bug 是可以理解，可以诊断的。

在介绍可见性、原子性、有序性的时候，提到缓存导致的可见性问题，线程切换带来的原子性，编译优化带来的有序性问题，其实这些目的都是相同的，就是提高程序的性能，但是解决一个问题就带来了另一个问题，瑕不掩瑜，所以我们使用的时候需要我们知道边界在哪里。出现了问题才能不慌~~~