可见性、原子性和有序性问题:并发编程Bug的源头

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

你我都知道,编写正确的并发程序是一件极困难的事情,并发程序的 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),欢迎关注、学习更多干货~

推荐阅读更多精彩内容