关于java:Java并发编程实战二并发编程Bug的源头可见性原子性和有序性问题

如果你仔细察看的话，你会发现，不论是哪一门编程语言，并发类的常识都是在高级篇里。换句话说，这块知识点其实对于程序员来说，是比拟进阶的常识。我本人这么多年学习过去，也的确感觉并发是比拟难的，因为它会波及到很多的底层常识，比方若你对操作系统相干的常识无所不知的话，那去了解一些原理就会费些力量。这是咱们整个专栏的第一篇文章，我说这些话的意思是如果你在两头遇到本人没想通的问题，能够去查阅材料，也能够在评论区找我，以保障你可能跟上学习进度。

你我都晓得，编写正确的并发程序是一件极艰难的事件，并发程序的 Bug 往往会诡异地呈现，而后又诡异地隐没，很难重现，也很难追踪，很多时候都让人很抓狂。但要疾速而又精准地解决“并发”类的疑难杂症，你就要了解这件事件的实质，寻根究底，深入分析这些 Bug 的源头在哪里。

那为什么并发编程容易出问题呢？它是怎么出问题的？明天咱们就重点聊聊这些 Bug 的源头。

这些年，咱们的 CPU、内存、I/ O 设施都在一直迭代，一直朝着更快的方向致力。然而，在这个疾速倒退的过程中，有一个外围矛盾始终存在，就是这三者的速度差别。CPU 和内存的速度差别能够形象地形容为：CPU 是天上一天，内存是地上一年（假如 CPU 执行一条一般指令须要一天，那么 CPU 读写内存得期待一年的工夫）。内存和 I / O 设施的速度差别就更大了，内存是天上一天，I/ O 设施是地上十年。

程序里大部分语句都要拜访内存，有些还要拜访 I /O，依据木桶实践（一只水桶能装多少水取决于它最短的那块木板），程序整体的性能取决于最慢的操作——读写 I / O 设施，也就是说单方面进步 CPU 性能是有效的。

为了正当利用 CPU 的高性能，均衡这三者的速度差别，计算机体系结构、操作系统、编译程序都做出了奉献，次要体现为：

CPU 减少了缓存，以平衡与内存的速度差别；
操作系统减少了过程、线程，以分时复用 CPU，进而平衡 CPU 与 I / O 设施的速度差别；
编译程序优化指令执行秩序，使得缓存可能失去更加正当地利用。

当初咱们简直所有的程序都默默地享受着这些成绩，然而天下没有收费的午餐，并发程序很多诡异问题的本源也在这里。

在单核时代，所有的线程都是在一颗 CPU 上执行，CPU 缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来说肯定是可见的。例如在上面的图中，线程 A 和线程 B 都是操作同一个 CPU 外面的缓存，所以线程 A 更新了变量 V 的值，那么线程 B 之后再拜访变量 V，失去的肯定是 V 的最新值（线程 A 写过的值）。如下所示是 CPU 缓存与内存之间的关系图：

一个线程对共享变量的批改，另外一个线程可能立即看到，咱们称为可见性。

多核时代，每个 CPU 都有本人的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。比方下图中，线程 A 操作的是 CPU- 1 上的缓存，而线程 B 操作的是 CPU- 2 上的缓存，很显著，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。这个就属于硬件程序员给软件程序员挖的“坑”。
多核 CPU 的缓存与内存关系图如下所示：

上面咱们再用一段代码来验证一下多核场景下的可见性问题。上面的代码，每执行一次 add10K()办法，都会循环 10000 次 count+= 1 操作。在 calc()办法中咱们创立了两个线程，每个线程调用一次 add10K()办法，咱们来想一想执行 calc()办法失去的后果应该是多少呢？

    public class Test {
        private long count = 0;

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

        public long calc() 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();
            return count;
        }
    }

直觉通知咱们应该是 20000，因为在单线程里调用两次 add10K()办法，count 的值就是 20000，但实际上 calc()的执行后果是个 10000 到 20000 之间的随机数。为什么呢？

咱们假如线程 A 和线程 B 同时开始执行，那么第一次都会将 count=0 读到各自的 CPU 缓存里，执行完 count+=1 之后，各自 CPU 缓存里的值都是 1，同时写入内存后，咱们会发现内存中是 1，而不是咱们冀望的 2。之后因为各自的 CPU 缓存里都有了 count 的值，两个线程都是基于 CPU 缓存里的 count 值来计算，所以导致最终 count 的值都是小于 20000 的。这就是缓存的可见性问题。

循环 10000 次 count+= 1 操作如果改为循环 1 亿次，你会发现成果更显著，最终 count 的值靠近 1 亿，而不是 2 亿。如果循环 10000 次，count 的值靠近 20000，起因是两个线程不是同时启动的，有一个时差。
变量 count 在 CPU 缓存和内存的分布图：

因为 IO 太慢，晚期的操作系统就创造了多过程，即使在单核的 CPU 上咱们也能够一边听着歌，一边写 Bug，这个就是多过程的功绩。

操作系统容许某个过程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会从新抉择一个过程来执行（咱们称为“工作切换”），这个 50 毫秒称为“工夫片 ”。线程切换示意图：

在一个工夫片内，如果一个过程进行一个 IO 操作，例如读个文件，这个时候该过程能够把本人标记为“休眠状态”并出让 CPU 的使用权，待文件读进内存，操作系统会把这个休眠的过程唤醒，唤醒后的过程就有机会从新取得 CPU 的使用权了。

这里的过程在期待 IO 时之所以会开释 CPU 使用权，是为了让 CPU 在这段等待时间里能够做别的事件，这样一来 CPU 的使用率就上来了；此外，如果这时有另外一个过程也读文件，读文件的操作就会排队，磁盘驱动在实现一个过程的读操作后，发现有排队的工作，就会立刻启动下一个读操作，这样 IO 的使用率也上来了。

是不是很简略的逻辑？然而，尽管看似简略，反对多过程分时复用在操作系统的发展史上却具备里程碑意义，Unix 就是因为解决了这个问题而名噪天下的。

晚期的操作系统基于过程来调度 CPU，不同过程间是不共享内存空间的，所以过程要做工作切换就要切换内存映射地址，而一个过程创立的所有线程，都是共享一个内存空间的，所以线程做工作切换老本就很低了。古代的操作系统都基于更轻量的线程来调度，当初咱们提到的“工作切换”都是指“线程切换”。

Java 并发程序都是基于多线程的，天然也会波及到工作切换，兴许你想不到，工作切换居然也是并发编程里诡异 Bug 的源头之一。工作切换的机会大多数是在工夫片完结的时候，咱们当初根本都应用高级语言编程，高级语言里一条语句往往须要多条 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 之前，也能够产生在 count+= 1 之后，但就是不会产生在两头。咱们把一个或者多个操作在 CPU 执行的过程中不被中断的个性称为原子性。CPU 能保障的原子操作是 CPU 指令级别的，而不是高级语言的操作符，这是违反咱们直觉的中央。因而，很多时候咱们须要在高级语言层面保障操作的原子性。

那并发编程里还有没有其余有违直觉容易导致诡异 Bug 的技术呢？有的，就是有序性。顾名思义，有序性指的是程序依照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”，在这个例子中，编译器调整了语句的程序，然而不影响程序的最终后果。不过有时候编译器及解释器的优化可能导致意想不到的 Bug。

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

这看上去所有都很完满，无懈可击，但实际上这个 getInstance()办法并不完满。问题出在哪里呢？出在 new 操作上，咱们认为的 new 操作应该是：

调配一块内存 M；
在内存 M 上初始化 Singleton 对象；
而后 M 的地址赋值给 instance 变量。

然而实际上优化后的执行门路却是这样的：

调配一块内存 M；
将 M 的地址赋值给 instance 变量；
最初在内存 M 上初始化 Singleton 对象。

优化后会导致什么问题呢？咱们假如线程 A 先执行 getInstance()办法，当执行完指令 2 时恰好产生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance()办法，那么线程 B 在执行第一个判断时会发现 instance != null，所以间接返回 instance，而此时的 instance 是没有初始化过的，如果咱们这个时候拜访 instance 的成员变量就可能触发空指针异样。
双重查看创立单例的异样执行门路示意图：

要写好并发程序，首先要晓得并发程序的问题在哪里，只有确定了“靶子”，才有可能把问题解决，毕竟所有的解决方案都是针对问题的。并发程序经常出现的诡异问题看上去十分无厘头，然而深究的话，无外乎就是直觉坑骗了咱们，只有咱们可能深刻理解可见性、原子性、有序性在并发场景下的原理，很多并发 Bug 都是能够了解、能够诊断的。

在介绍可见性、原子性、有序性的时候，特意提到缓存导致的可见性问题，线程切换 带来的原子性问题，编译优化带来的有序性问题，其实缓存、线程、编译优化 的目标和咱们写并发程序的目标是雷同的，都是进步程序性能。然而技术在解决一个问题的同时，必然会带来另外一个问题，所以在 采纳一项技术的同时，肯定要分明它带来的问题是什么，以及如何躲避。

咱们这个专栏在解说每项技术的时候，都会尽量将每项技术解决的问题以及产生的问题讲清楚，也心愿你可能在这方面多思考、多总结。

关于java:Java并发编程实战二并发编程Bug的源头可见性原子性和有序性问题

引言

并发程序幕后的故事

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

源头之二：线程切换带来的原子性问题

源头之三：编译优化带来的有序性问题

总结