（一）并发编程BUG的源头：可见性、原子性、有序性问题

可见性：一个线程对共享变量的修改，另一个线程能够立刻看到

原子性：我们把一个或多个操作在CPU执行过程中不被中断的特性称为原子性。

有序性：是指程序按照代码的先后次序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序

并发程序幕后的故事

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

程序里大部分语句都要访问内存，有些还要访问I/O，根据木桶理论（一只水桶能装多少水取决于它最短的那块木板），程序整体的性能取决于最慢的操作——读写I/O设备，也就是说单方面提高CPU性能是无效的。

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

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

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

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

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

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

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

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

如图，线程A操作的是CPU-1上的缓存，而线程B操作的是CPU-2上的缓存，很明显这个时候线程A对变量V的操作对于线程B而言就不具备可见行了，这个就属于硬件程序员给软件程序员挖的“坑”。

3.代码举例：

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指令级别的，而不是高级语言级别的。因此我们很多时候需要在高级语言层面保证操作的原子性。

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

有序性是指程序按照代码的先后次序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，如“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操作应该是：

分配一块内存M；

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

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

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

分配一块内存M；

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

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

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

总结

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