你的 Java 并发程序 Bug，100% 是这几个缘由形成的

可见性问题

可见性是指一个线程对共享变量进行了修改，其余线程可以立马看到该共享变量更新后的值，这视乎是一个合情合理的要求，可是在多线程的状况下，可能就要让你失望了，因为每一个 CPU 都有本身的缓存，每一个线程使用的多是不一样的 CPU ，这就会出现数据可见性的问题，先来看看下面这张图：

对于一个共享变量 count ，每一个 CPU 缓存中都有一个 count 副本，每一个线程对共享变量 count 的操做的只能操做本身所在 CPU 缓存中的副本，不能直接操做主存或者其余 CPU 缓存中的副本，这也就产生了数据差别。因为可见性在多线程状况下形成程序问题的典型案例就是变量的累加，以下面这段程序：

public class Demo {

    private int count = 0;

    // 每一个线程为count + 10000
    public void add() {
        for (int i = 0; i < 10000; i++) {
            count += 1;
        }
    }

    public static void main(String[] args) throws InterruptedException {

        for (int i = 0; i < 10; i++) {
            Demo demo = new Demo();
            Thread t1 = new Thread(() -> {
                demo.add();
            });
            Thread t2 = new Thread(() -> {
                demo.add();
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println(demo.count);
        }
    }
}
复制代码

咱们使用了 2 个程序对 count 变量累加，每一个线程累加 10000 次，按道理来讲最终结果应该是 20000 次，可是你屡次执行后，你会发现结果不必定是 20000 次，这就是因为共享变量的可见性形成的。

咱们启动了两个线程 t1 和 t2，线程启动的时候会把当前主内存的 count 读入到本身的 CPU 缓存当中，这时候 count 的值多是 0 也多是 1 或者其余，咱们就默认为 0，每一个线程都会执行 count += 1 操做，这是一个并行操做，CPU1 和 CPU2 缓存中的 count 都是 1，而后他们分别将本身缓存中的count 写回到主内存中，这时候主内存中的 count 也是 1 ，并非咱们预计的 2,。这个缘由就是数据可见性形成的。

原子性问题

原子性：即一个操做或者多个操做，要么所有执行而且执行的过程不会被任何因素打断，要么就都不执行。这个原子性针对的是 CPU 级别的，并非咱们 Java 代码里面的原子性，拿咱们可见性 Demo 程序中的 count += 1;命令为例，这一条 Java 命令最终会被编译成以下三条 CPU 指令：

• 把变量 count 从内存加载到 CPU 的寄存器，假设 count = 1
• 在寄存器中执行 count +1 操做，count = 1+1 =2
• 将结果 +1 后的 count 写入内存

这是一个典型的 读-改-写 的操做，可是它不是原子性的，由于 多核CPU 之间有竞争关系，并非某一个 CPU 一直执行，他们会不断的抢占执行权、释放执行权，因此上面三条指令就不必定是原子性的，下图是两个线程 count += 1命令的模拟流程：

线程1 所在的 CPU 执行完前两条指令后，执行权被 线程2 所在的 CPU 抢占了，这时候线程1 所在的 CPU 执行挂起等待再次获取执行权，线程2 所在的 CPU 获取到执行权以后，先从内存中读取 count，此时内存中的 count 仍是 1，线程2 所在的 CPU 刚好执行完了这三条指令，线程2 执行完以后内存中的 count 就等于 2 了，这时候线程1 再次获取了执行权，这时候线程1 只剩下最后一条将 count 写回内存的命令，执行完以后，内存中的 count 的值仍是 2 ，并非咱们预计的 3。

有序性问题

有序性：程序执行的顺序按照代码的前后顺序执行，好比下面这段代码

1  int i = 1;
2  int m = 11;
3  long x = 23L;
复制代码

按照有序性的话就须要按照代码的顺序执行下来，可是执行结果不必定是按照这个顺序来的，由于 JVM 为了提升程序的运行效率，会对上面的代码按照 JVM 编译器认为最优的顺序执行，从而可能打乱代码的执行顺序，是它会保证程序最终执行结果和代码顺序执行的结果是一致的，这也就是咱们所说的指令重排序

因为指令重排序形成程序出 Bug 的典型案例就是：未加 volatile 关键字的双重检测锁单例模式，以下代码：

public class Singleton { 
	static Singleton instance; 
	public static Singleton getInstance(){ 
	// 第一次判断
	if (instance == null) { 
		// 加锁，只有一个线程可以获取锁
		synchronized(Singleton.class) { 
			// 第二次判断
			if (instance == null) 
				// 构建对象，这里面就很是有学问了
				instance = new Singleton(); 
			} 
	}
	return instance; 
	} 
}
复制代码

双重检测锁方案看上去很是完美，可是在实际运行时却会出 Bug，会出现对象逸出的问题，可能会获得一个未构建完的 Singleton 对象， 这个就是在构建 Singleton 对象时指令重排序的问题。咱们先来看看构建对象理想型的操做指令：

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

可是实际在 JVM 编译器上可能不是这样，可能会被优化成以下指令：

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

看上去一个小小的优化，也就是这么一个小小的优化就会使你的程序不安全，假设抢到锁的线程执行完指令2 以后，此时的 instance 已经不为空了，这时候来了线程C，线程C 看到的 instance 已是不为空的了，就会直接返回 instance 对象，这时候的 instance 并未初始化成功，调用 instance 对象的方法或者成员变量时将有可能触发空指针异常。可能的执行流程图：

上面就是形成 Java 程序在多线程状况下出 Bug 的三种缘由，关于这些问题 JDK 公司也给出了相应的解决办法，具体以下图所示，这些解决办法的更多细节，咱们后面在细细道来。

文章不足之处，望你们多多指点，共同窗习，共同进步

最后

打个小广告，欢迎扫码关注微信公众号：「平头哥的技术博文」，一块儿进步吧。