01.并发编程中可见性、原子性、有序性问题

并发编程幕后的故事

       这些年，我们的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. 编译程序优化指令执行次序，使得缓存能够得到更加合理地应用

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

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

    在单核时代，所有的线程都是在一粒cpu上执行，cpu缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个cpu的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。如下图所示：线程A和线程B都是操作同一个cpu里面的缓存，所以线程A更新了变量V的值，那么线程B之后再访问变量V，得到的一定是V的最新值（线程A写过的值）。

一个线程对共享变量的修改，另外一个线程能够立即看到，我们成为可见性。

多核时代，每粒cpu都有自己的缓存，很明显，这个时候线程A对变量V的操作对于线程B而言就不具备可见性了。

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

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，因为单线程里调用两次add10k()方法，count的值就是20000，但实际上calc()的执行结果是个10000到20000之间的随机数。why?

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

循环10000次count+=1操作如果改为循环一亿次，会发现效果更明显，最终count的值接近1亿，而不是两亿。如果循环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指令。

• 指令一：首先，需要把变量count从内存加载到cpu的寄存器
• 指令二：之后，在寄存器中执行+1操作
• 指令三：最后，将结果写入内存（缓存机制导致可能写入的是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变量

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

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

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