并发编程的Bug源头与解决思路

因为现代计算机中CPU、内存、I/O操作存在性能差异问题，而一个程序的完整执行往往需要CPU、内存、I/O操作共同完成；例如进行I/O操作时，此时CPU就是空闲状态，浪费其性能，所以需要通过并发程序来提升硬件设备的使用率，提高程序性能。

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

现代计算机多核CPU都是标配，普通个人电脑4核、8核都很常见，更不用现代服务器的16核、32核等。因为每个CPU都有自己的高速缓存（1、2、3级缓存），这就会导致我们的线程在处理共享变量时，因为操作的数据在各自CPU的高速缓存中，导致可见性问题。

public class Test {

    private long count = 0;

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

    public static void main(String[] args) throws InterruptedException {
        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();
        System.out.println(test.count);
    }
}

如上代码所示：当我们有两个线程分别调用add10K()方法时，最后的count值总是小于20000；因为在多核CPU下，每个线程可能操作的都是自己CPU的高速缓存，导致最后的数据小于2000次。

Bug源头二——编译导致的指令重排序

有序性指的是程序按照代码的先后顺序执行，但是因为编译器的优化，代码的真实执行顺序，并不一定是我们写代码的顺序，而指令重排就会导致一定的问题，例如单例模式中的双重检查创建单例对象，就是因为指令重排优化导致问题。如下代码所示

public class Singleton {
  static Singleton instance;
  static Singleton getInstance(){
    if (instance == null) {
      synchronized(Singleton.class) {
        if (instance == null)
          instance = new Singleton();
        }
    }
    return instance;
  }
}

在j我们认为的new一个对象是如下步骤：

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

实际执行流程如下

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

导致的问题就是：假设，现在有两个线程A，B线程执行到了new
Singleton()方法的第二部，将M的地址赋值给instance变量；此时发生了CPU切换B线程执行的是第一个null值判断，此时instance不为null，但此时内存上还未初始化对象，这时就可能发生空指针问题。

Java内存模型

java内存模式是java语言提出的规范，是用来描述多线程间的特性，描述了多线程程序的合法行为，即为多线程程序定义的一套规则​；规范了 JVM 如何提供按需禁用缓存和编译优化的方法。也就是帮我们解决了缓存问题和指令优化导致的并发问题。

volatile关键字的作用

• 使用volatile修饰的变量，对这个变量的读写，不能使用 CPU 缓存，必须从内存中读取或者写入
• 对volatile变量相关的指令不做​重排操作。

Happens-Before 规则:表示前面的操作一定是对后面的操作是可见的；Happens-Before 约束了编译器的优化行为，虽允许编译器优化，但是要求编译器优化后一定遵守 Happens-Before 规则。

1. 程序顺序原则：一个线程内保证语义的串行化。
2. volatile规则：volatile变量的写，先发生于读，这保证了volatile变量的可见性。
3. 锁规则：解锁（unlock）必然发生在随后的加锁（lock）前。
4. 传递性：A先于B，B先于C，那么A必然先于C
5. 线程的start()方法先于它的每一个动作
6. 线程的所有操作先于线程的终结（Thread.join()）
7. 线程的中断（interrupt()）先于被中断线程的代码
8. 对象的构造函数执行、结束先于finalize（）方法。

Bug源头 —— 线程切换带来的原子性问题

现代CPU的设计，对于CPU的使用都是采用时间片的方式，假设这个时间为50毫秒，每个线程在使用50毫秒后，就会自动让出CPU使用，别的线程就可重新获取CPU使用权，而往往我们写的程序需要多个CPU指令在能完成，这个时候我们的操作就不是原子性的，在发生CPU切换时就会出现问题；例如在java中count++操作，在CPU层面就是非原子性的，在CPU中需要3步才能完成这个操作：

1. 需要把变量 count 从内存加载到 CPU 的寄存器；
2. 在寄存器中执行 +1 操作；
3. 将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）

而CPU的切换可能发生在上述步骤中的任意一步中，这就会导致每个CPU读到的值就是所谓的“脏数据”

锁

原子性的源头就是线程切换，这个时候对于共享资源，我们就需要做到“同一时刻只有一个线程执行”，这个就称为互斥。我们把一段需要互斥执行的代码称为临界区。

在java中提供了很多关于锁实现的方式，例如synchronized关键字、ReenLock等实现，其根本目的就是为了保证，代码临界区的原子性。