Java并发编程Bug的源头

相信大家都听说过并发编程，面试中也经常会被提问这一知识点，有时候让讲讲自己有没有并发编程的经验，细致地讲一下。结果可想而知，理论知识还可以说一说，但没多少实践经验，更让人头疼的是理论与实践差距极大。在工作中，系统的并发量比较低，借助数据库和类似 Tomcat 这种中间件，我们基本上不用写并发程序。

总之一句话，系统并发量不高的时候，并发问题基本上都被中间件和数据库解决了，或者系统数据量比较庞大，对性能有所要求，此时就需要用到并发编程了。

并发编程是个好东西，但天下没有免费的午餐，凡事都是有代价的，获得高性能的同时，也要承受并发程序带来的诸多问题。

缓存导致的可见性问题

可见性（共享对象可见性）：线程对共享变量修改的可见性。当一个线程修改了共享变量的值，其他线程能够立刻得知这个修改。

在 Java内存模型一文中有介绍线程与工作内存、主内存之间的关系，没啥印象可以去回顾一下。

如果两个或者更多的线程共享一个对象，一个线程更新这个共享对象可能对其它线程来说是不可见的：共享对象被初始化在主存中。跑在CPU上的一个线程将这个共享对象读到CPU缓存中，然后修改了这个对象。只要CPU缓存没有被刷新会主存，对象修改后的版本对跑在其它CPU上的线程都是不可见的。这种方式可能导致每个线程拥有这个共享对象的私有拷贝，每个拷贝停留在不同的CPU缓存中。

下图示意了这种情形。跑在左边 CPU 的线程拷贝这个共享对象到它的 CPU 缓存中，然后将 count 变量的值修改为2。这个修改对跑在右边CPU 上的其它线程是不可见的，因为修改后的 count 的值还没有被刷新回主存中去。

我们通过下属案例进行演示，当线程B更改了 stopRequested 变量的值之后，但是还没来得及写入主存当中，线程B转去做其他事情了，那么线程A由于不知道线程B对 stopRequested 变量的更改，因此还会一直循环下去。

public class VisibilityCacheTest {

  private static boolean stopRequested = false;

  public static void main(String[] args) throws InterruptedException {
    Thread thread1 = new Thread(() -> {
      int i = 0;
      while (!stopRequested) {
        i++;
      }
    },"A");

    Thread thread2 = new Thread(() -> {
      stopRequested = true;
    },"B");

    thread1.start();
    TimeUnit.SECONDS.sleep(1);  //为了演示死循环，特意sleep一秒
    thread2.start();
  }
}

这段代码是很典型的一段代码，很多人在中断线程时可能都会采用这种标记办法。但是事实上，这段代码会完全运行正确么？即一定会将线程中断么？不一定，也许在大多数时候，这个代码能够把线程中断，但是也有可能会导致无法中断线程（虽然这个可能性很小，但是只要一旦发生这种情况就会造成死循环了）。

线程切换带来的原子性问题

即使是单核处理器也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程是同时执行的，时间片一般是几十毫秒（ms）。

CPU 通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。

线程切换示意图如下所示：

我们还是通过一个经典案例来进行演示：

public class AtomicityTest {

  static int count = 0;

  public static void main(String[] args) throws InterruptedException {
    AtomicityTest obj = new AtomicityTest();
    Thread t1 = new Thread(() -> {
      obj.add();
    }, "A");

    Thread t2 = new Thread(() -> {
      obj.add();
    }, "B");

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

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

    System.out.println("main线程输入结果为==>" + count);
  }

  public void add() {
    for (int i = 0; i < 100000; i++) {
      count++;
    }
  }
}

上面这段代码做的事情很简单，开了 2 个线程对同一个共享整型变量分别执行十万次加1操作，我们期望最后打印出来 count 的值为200000，但事与愿违，运行上面的代码，count 的值是极有可能不等于 20万的，而且每次运行结果都不一样，总是小于 20万。为什么会出现这个情况呢？

自增操作是不具备原子性的，它包括读取变量的原始值、进行加1操作、写入工作内存。那么就是说自增操作的三个子操作可能会分割开执行，就有可能导致下面这种情况出现：

假如某个时刻变量 count 的值为10，

线程A对变量进行自增操作，线程A先读取了变量 count 的原始值，然后线程A被阻塞了（可能存在的情况）；

然后线程B对变量进行自增操作，线程B也去读取变量 count 的原始值，由于线程A只是对变量 count 进行读取操作，而没有对变量进行修改操作，所以主存中 count 的值未发生改变，此时线程B会直接去主存读取 count 的值，发现 count 的值为10，然后进行加1操作，并把11写入工作内存，最后写入主存。

然后线程A接着进行加1操作，由于已经读取了 count 的值，注意此时在线程A的工作内存中 count 的值仍然为10，所以线程A对 count 进行加1操作后 count 的值为11，然后将11写入工作内存，最后写入主存。

那么两个线程分别进行了一次自增操作后，inc只增加了1。

编译优化带来的有序性问题

在 Java 高并发系列开始时，第一篇文章介绍了计算机的一些基础知识。处理器为了提高 CPU 的效率，通常会采用指令乱序执行的技术，即将两个没有数据依赖的指令乱序执行，但并不会影响最终的结果。与处理器的乱序执行优化类似，Java 虚拟机的即时编译器中也有类似的指令重排序（Instruction Reorder）优化。

在 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 实例。

实例化一个对象其实可以分为三个步骤：

（1）分配内存空间。

（2）初始化对象。

（3）将内存空间的地址赋值给对应的引用。

但是由于操作系统可以对指令进行重排序，所以上面的过程也可能会变成如下过程：

（1）分配内存空间。

（2）将内存空间的地址赋值给对应的引用。

（3）初始化对象

如果是这个流程，多线程环境下就可能将一个未初始化的对象引用暴露出来，从而导致不可预料的结果。

总结

要写好并发程序，首先要知道并发程序的问题在哪里，只有确定了“靶子”，才有可能把问题解决，毕竟所有的解决方案都是针对问题的。

缓存、线程、编译优化的目的和我们写并发程序的目的是相同的，都是提高程序性能。但是技术在解决一个问题的同时，必然会带来另外一个问题，所以在采用一项技术的同时，一定要清楚它带来的问题是什么，以及如何规避。