用5000字来聊聊并发编程的源头：可见性、原子性和有序性

0 目录

1 并发编程的起源

2 罪魁祸首之一“CPU缓存导致的可见性问题”

3 罪魁祸首之二“线程上下文切换带来的原子性问题”

4 罪魁祸首之三“编译优化带来的有序性问题”

5 总结

6 考察一个知识点

工作做螺丝钉，面试造火箭，我想这个是每个程序员比较头疼的事情，但是又有必须经历的流程，我们再聊聊高并发中的原子性、可见性和有序性。

我们可以尝试的推演下，不管是Java、Go还是C++等其他语言，我们会发现，并发编程都属于非常难的知识点，也是从普通程序员向高级程序员进阶的必经之路。我们都知道编写正确的并发程序是一件极困难的事情，并发程序的 Bug 往往会诡异地出现，然后又诡异地消失，很难重现，也很难追踪，很多时候都让人很抓狂。但要快速而又精准地解决“并发”类的疑难杂症，你就要理解这件事情的本质，追本溯源，深入分析这些 Bug 的源头在哪里。

1 并发编程的起源

计算机设备中，CPU、内存、I/O 设备都在不断迭代，不断朝着更快的方向努力。但是，在这个快速发展的过程中，有一个核心矛盾一直存在，就是这三者的速度差异太大，懂计算机硬件的应该非常清楚，差异性不止一个量级。

CPU 和内存的速度差异可以形象地描述为：CPU 是天上一天，内存是地上一年（假设 CPU 执行一条普通指令需要一天，那么 CPU 读写内存得等待一年的时间）。

内存和 I/O 设备的速度差异就更大了，内存是天上一天，I/O 设备是地上十年。

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

为了合理利用 CPU 的高性能，平衡这三者的速度差异，计算机体系结构、操作系统、编译程序都做和很多优化，只是这些优化我们并不是都清楚。

主要包括如下：

• CPU 增加了缓存，以均衡与内存的速度差异；
• 操作系统增加了进程、线程，以分时复用 CPU，进而均衡 CPU 与 I/O 设备的速度差异；
• 编译程序优化指令执行次序，使得缓存能够得到更加合理地利用。

当计算机为了提升性能，做了这么多自动优化策略之后，性能的确是提升了，但是我们程序员并不一定全知道这些策略。凡是有利必有弊，这个是亘古不变的道理，并发程序很多诡异问题的根源就会出在这些性能优化的策略之上。

2 罪魁祸首之一“CPU缓存导致的可见性问题”

在计算机的单核时代，所有的线程都是在一个CPU核心 上运行，CPU 缓存与内存的数据一致性容易解决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来说一定是可见的。

我们通常把一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。

但是在计算机的多核时代，每个CPU核心 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 核心上执行时，这些线程操作的是不同的 CPU 缓存，这样数据一致性是很难保证的。

也就是说CPU缓存是导致的可见性问题的罪魁祸首，哈哈，我是不是可以这么想，我可以禁止使用CPU缓存啊，这样不就完美的解决了。但是你试着想一下，那样你是不是不能充分的利用计算机的这个优化性能的策略了呢？

3 罪魁祸首之二“线程上下文切换带来的原子性问题”

在计算机操作系统中，由于 I/O 太慢，计算机的发明者很早就就发明了多进程，这样我们在单核的 CPU 上我们也可以一边看电影，一边写 代码，这个就是多进程的功劳。操作系统允许某个进程执行一小段时间，例如 10 毫秒，过了 10 毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），二这个 10 毫秒称为“时间片”。

在一个时间片内，如果有一个进程进行一个 I/O 操作，例如读个文件，这个时候该进程可以把自己标记为“休眠状态”并出让 当前CPU核心 的使用权，待文件读进内存，操作系统会把这个休眠的进程唤醒，唤醒后的进程就有机会重新获得 CPU 的使用权了。

进程在等待 I/O 时之所以会释放 CPU 使用权（通常I/O操作都是阻塞的），是为了让 CPU 核心在本次I/O阻塞的时间片内可以执行其它的任务（当然也可以是I/O任务），这样就可以提高CPU核心的利用率了。

此外，如果这时有另外一个进程也读文件，读文件的操作就会排队，磁盘驱动在完成一个进程的读操作后，发现有排队的任务，就会立即启动下一个读操作，这样I/O 的使用率也上来了。

是不是很简单的逻辑？但是，虽然看似简单，支持多进程分时复用在操作系统的发展史上却具有里程碑意义，Unix 就是因为解决了这个问题而名噪天下的。

早期的操作系统基于进程来调度 CPU，不同进程间是不共享内存空间的，所以进程要做任务切换就要切换内存映射地址，而一个进程创建的所有线程，都是共享一个内存空间的，所以线程做任务切换成本就很低了。现代的操作系统都基于更轻量的线程来调度，现在我们提到的“任务切换”都是指“线程切换”。

Java 并发程序都是基于多线程的，自然也会涉及到任务切换，但是任务切换是并发编程里诡异 Bug 的源头之一。任务切换的时机大多数是在时间片结束的时候，我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条 CPU 指令完成，例如上面代码中的count += 1，至少需要三条 CPU 指令，这个就是根源，因为我们程序员以为我只执行了一条语句，就算是在多线程环境里面，也不会出现线程安全的问题，但是呢CPU解析这条语句，是需要用多条指令执行的，也就是说你可能认为你的这语句是原子性的，但是人家CPU觉得是多条指令，不是原子性的，这样就会出现问题。

我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。CPU 能保证的原子操作是 CPU 指令级别的，而不是高级语言的操作符，这是违背我们直觉的地方。因此，很多时候我们需要在高级语言层面保证操作的原子性。

我来列举一个非常形象的例子：自从肺炎出来之后，你会发现节假日你去景区游玩，外面都是排了老长的队，比如笔者就在十一去过上海的东方明珠。本来检票入口只有一个，验证门票和身份证（只需要增加这样流程的入口多一点就好了），但是肺炎出来之后，就多了校验健康码行程码，并且还要登记入员信息等流程，这样这个入口就严重拥堵了，所有人都会被直接排挤到门口，体验非常差。

为了提升游客游玩的体检，聪明的检票人员就将这些流程拆分为多个，并加长检票的路线，将这条路线按照流程的个数，拆分成多个不流程的检票口，比如第一个入口检查健康码、第二个入口检查行程码等。经过这样优化之后，人数还是那么多（比如10万人要去东方明珠），也还是在等待，但是呢，后面待入园的人会感觉在前进，哈哈虽然很慢，但至少不是原地不动。

如上就是一个典型的多线程切换的业务应用场景，其实呢生活中还有很多这样的例子。

4 罪魁祸首之三“编译优化带来的有序性问题”

那并发编程里还有没有其他有违直觉容易导致诡异 Bug 的技术呢？有的，就是有序性。顾名思义，有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改变程序中语句的先后顺序，就是因为会改变执行的顺序，就会出现意想不到的错误，这些错误是程序员从实际代码层去review不出来的，所有这个时候需要程序员懂JVM底层的原理，这也是很多面试官否会考察虚拟机知识的原因。

当然JVM中有很多措施去规避编译优化带来的有序性问题，比如最简单的措施是JVM的happen-before原则。

5 总结

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

这些都是笔者对Java并发编程中“原子性”、“可见性”和“有序性”的理解，如果觉得有哪些不对的地方可以留言并交流技术。

6 考察一个基础知识点

如下代码会存在空指针的异常吗？（主要考察大家对Java的switch语法的了解程度）它是RocketMQ中请求-应答消息模型中的代码，感兴趣的读者可以留言。

@Override
protected SendMessageRequestHeader parseRequestHeader(RemotingCommand request) throws RemotingCommandException {
    SendMessageRequestHeaderV2 requestHeaderV2 = null;
    SendMessageRequestHeader requestHeader = null;
    switch (request.getCode()) {
        case RequestCode.SEND_REPLY_MESSAGE_V2:
            requestHeaderV2 =
                (SendMessageRequestHeaderV2) request
                        .decodeCommandCustomHeader(SendMessageRequestHeaderV2.class);
        case RequestCode.SEND_REPLY_MESSAGE:
            if (null == requestHeaderV2) {
                requestHeader =
                    (SendMessageRequestHeader) request
                        .decodeCommandCustomHeader(SendMessageRequestHeader.class);
            } else {
                requestHeader = SendMessageRequestHeaderV2.createSendMessageRequestHeaderV1(requestHeaderV2);
            }
        default:
            break;
    }
    return requestHeader;
}

知识输出是笔者的初衷，借助知识输出，能够认识更多的牛人,能够和牛人沟通，也是自己技术提升的一个机会。