java多线程基础篇（三）多线程并发问题的根因

并发编程Bug的源头

原子性 Synchronized， AtomicXXX、Lock、
可见性 Synchronized， volatile
有序性 Synchronized，volatile

原子性问题

在下面的案例中，演示了两个线程分别去去调用demo.incr 方法来对i 这个变量进行叠加，预期结果
应该是20000，但是实际结果却是小于等于20000的值。

package com.lf.thread.status;

public class Demo {
    int i = 0;

    public void incr() {
        i++;
    }

    public static void main(String[] args) {
        Demo demo = new Demo();
        Thread[] threads = new Thread[2];
        for (int j = 0; j < 2; j++) {
            threads[j] = new Thread(() -> { // 创建两个线程
                for (int k = 0; k < 10000; k++) { // 每个线程跑10000次
                    demo.incr();
                }
            });
            threads[j].start();
        }
        try {
            threads[0].join();
            threads[1].join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(demo.i);
    }
}

运行结果每次都不同

产生问题的原因

这个就是典型的线程安全问题中原子性问题的体现。那什么是原子性呢？

在上面这段代码中，count++是属于Java高级语言中的编程指令，而这些指令最终可能会有多条CPU指
令来组成，而count++最终会生成3条指令， 通过javap -v xxx.class 查看字节码指令如下。

D:\ideaWorkspace\lf-es-kafka-demo\target\classes\com\lf\thread\status>javap -v Demo.class
Classfile /D:/ideaWorkspace/lf-es-kafka-demo/target/classes/com/lf/thread/status/Demo.class
  Last modified 2022-12-7; size 1826 bytes
  MD5 checksum 8d464c54105ad7bc08f9de5a848e7bc4
  Compiled from "Demo.java"
public class com.lf.thread.status.Demo
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
...

 public void incr();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #2                  // Field i:I // 访问变量i
         5: iconst_1                           // 将整形常量1放入操作数栈
         6: iadd          // 把操作数栈中的常量1出栈并相加，将相加的结果放入操作数栈
         7: putfield      #2// Field i:I//访问类字段（类变量），复制给Demo.i这个变量
        10: return
      LineNumberTable:
        line 7: 0
        line 8: 10
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      11     0  this   Lcom/lf/thread/status/Demo;

线程执行图如下:

这三个操作，如果要满足原子性，那么就需要保证某个线程在执行这个指令时，不允许其他线程干扰，
然后实际上，确实会存在这个问题。

可见性问题

对上述示例来说，我们假设线程 A 和线程 B 同时开始执行，那么第一次都会将 count=0 读到各自的 CPU 缓存里，执行完 count+=1 之后，各自 CPU 缓存里的值都是 1，同时写入内存后，我们会发现内存中是 1，而不是我们期望的 2。

之后由于各自的 CPU 缓存里都有了 count 的值，两个线程都是基于 CPU 缓存里的 count 值来计算，所以导致最终 count 的值都是小于 20000 的。这就是缓存的可见性问题。

有序性问题

双重检查创建单例对象，例如下面的代码：在获取实例 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 的成员变量就可能触发空指针异常。