为什么 Chromium 如此推崇异步非阻塞？——彻底搞懂同步、异步、阻塞、非阻塞

摘要

很多人学习网络编程时，都会遇到四个概念：

• 同步（Synchronous）
• 异步（Asynchronous）
• 阻塞（Blocking）
• 非阻塞（Non-blocking）

但真正理解的人却不多。

很多人把同步等同于阻塞，把异步等同于非阻塞。

事实上，它们根本不是一个维度。

本文将结合生活中的例子以及 Chromium 的源码设计，彻底讲明白这四者之间的关系。

---

一、为什么很多人会混淆？

很多教程一开始就画这样一张图：

同步
异步

阻塞
非阻塞

然后开始讲 API。

例如：

select()

epoll()

IOCP()

结果。

新人越来越迷糊。

其实原因很简单。

因为：

同步/异步

讨论的是：

结果是谁通知你的。

而：

阻塞/非阻塞

讨论的是：

等待期间，你能不能继续做别的事情。

它们描述的是两个完全不同的问题。

---

二、同步与异步：谁来通知结果？

这是第一个维度。

只有一句话。

同步：自己主动获取结果。

异步：别人主动通知结果。

注意。

这里和线程是否等待。

没有任何关系。

---

举个餐厅的例子。

你点了一碗牛肉面。

老板开始做。

第一种情况。

你每隔一分钟问一次：

老板，好了吗？

老板：

没有。

一分钟后。

你继续问。

老板，好了吗？

老板：

还没有。

整个过程。

结果是谁拿到的？

答案：

你自己不停去问。

这就是：

同步。

---

第二种情况。

老板说：

做好了我喊你。

你什么都不用问。

做好以后。

老板：

23号！

牛肉面好了！

结果是谁通知你的？

老板。

这就是：

异步。

所以。

同步异步。

只看一句话。

到底是谁主动告诉你结果。

---

三、阻塞与非阻塞：等待的时候在干什么？

这是第二个维度。

同样只有一句话。

阻塞：等待期间什么也做不了。

非阻塞：等待期间还能继续工作。

例如。

还是餐厅。

老板说：

站这等。

于是。

五分钟。

你一直站在那里。

不能走。

不能聊天。

不能玩手机。

这就是：

阻塞。

---

另一种情况。

老板说：

做好了自己来看。

于是。

你：

出去买奶茶

↓

回来问

↓

没好

↓

继续逛

↓

回来问

虽然。

结果还是：

自己问。

但是。

整个等待期间。

你一直在干别的事情。

这就是：

非阻塞。

---

四、四种组合

到这里。

其实已经可以组合出来四种情况。

---

第一种：同步阻塞

这是最经典的一种。

例如。

老板：

做好之前。

站这。

于是。

点餐

↓

等待

↓

拿面

↓

结束

整个过程。

既是：

自己拿结果。

又：

一直等待。

程序中。

例如：

ReadFile();

printf("继续执行");

ReadFile没有返回。

下面所有代码。

全部停止。

---

第二种：同步非阻塞

老板：

做好了自己来看。

于是。

你：

问一下

↓

没有

↓

出去逛

↓

回来问

↓

没有

↓

继续问

整个过程。

结果：

仍然是：

自己获取。

所以：

同步。

但是。

等待期间。

一直可以干别的。

因此：

非阻塞。

Linux Socket：

设置：

O_NONBLOCK

就是这种思想。

---

第三种：异步阻塞

很多人认为。

异步一定非阻塞。

其实不是。

例如。

老板：

做好了我喊你。

于是。

你：

一直坐门口。

等老板喊。

整个过程中。

老板负责通知。

所以：

异步。

但是。

你：

一直坐着。

不能干别的。

所以：

阻塞。

例如。

很多线程同步代码：

future.wait();

或者：

WaitableEvent.Wait();

线程：

一直睡眠。

等别人通知。

---

第四种：异步非阻塞

这是现代服务器最喜欢的方式。

老板：

做好以后。

微信通知。

于是。

你：

点餐

↓

出去购物

↓

喝咖啡

↓

老板发微信

↓

回来拿面

整个过程中。

老板：

负责通知。

你：

一直可以做自己的事情。

程序里：

例如：

ReadFileAsync();

继续执行其它代码；

......

完成以后：

Callback();

或者

async/await

IOCP

epoll

libuv

Node.js

都属于这一类。

---

五、一张图彻底记住

                    谁通知结果？

                自己问            别人通知
              (同步)             (异步)
────────────────────────────────────────
一直等待      同步阻塞        异步阻塞
(阻塞)

────────────────────────────────────────

继续干活      同步非阻塞      异步非阻塞
(非阻塞)

很多人看到这里。

突然就理解了。

因为：

同步异步。

讨论的是：

通知方式。

阻塞非阻塞。

讨论的是：

等待状态。

两个维度。

互不影响。

---

六、Chromium 为什么大量采用异步非阻塞？

理解完四种模式。

再来看 Chromium。

很多设计突然就合理了。

例如。

UI Thread。

如果执行：

ReadFile();

等待磁盘。

整个浏览器：

卡住。

用户：

不能点击。

不能输入。

不能滚动。

这就是：

同步阻塞。

Chrome几乎禁止。

---

真正的代码。

更像这样。

base::ThreadPool::PostTaskAndReply(
    FROM_HERE,
    base::BindOnce(&ReadFile),
    base::BindOnce(&OnReadFinished));

流程如下。

UI Thread

↓

PostTask()

↓

立即返回

↓

继续响应用户操作

↓

后台线程读取文件

↓

读取完成

↓

Reply()

↓

UI更新界面

注意。

整个过程中。

UI线程：

从未等待。

读取完成以后。

后台线程：

主动通知。

因此。

这就是：

异步非阻塞。

---

七、为什么现代高性能框架都选择异步非阻塞？

无论是：

• Chromium
• Node.js
• Nginx
• libuv
• Boost.Asio
• Windows IOCP
• Linux epoll

它们最终追求的目标。

其实只有一句话。

不要让 CPU 在等待中浪费时间。

真正昂贵的。

不是计算。

而是：

等待磁盘

等待网络

等待数据库

等待GPU

等待用户

如果线程一直阻塞。

CPU就在睡觉。

现代系统希望的是。

当一个任务等待IO的时候。

CPU立即去执行另一个任务。

IO完成以后。

系统再通知它回来。

这样。

CPU几乎一直处于工作状态。

吞吐量自然也就上去了。

---

八、总结

很多初学者把同步等同于阻塞，把异步等同于非阻塞，这是一个非常常见的误区。

实际上，这两组概念描述的是完全不同的两个维度：

• 同步还是异步，取决于谁负责获取结果。 自己主动查询是同步，对方完成后主动通知是异步。
• 阻塞还是非阻塞，取决于等待期间线程是否还能继续执行其他任务。 什么都做不了是阻塞，可以继续处理其他工作就是非阻塞。

理解了这两个维度，再去阅读 Chromium 的 PostTask()、ThreadPool、Sequence、WaitableEvent，以及 Linux 的 epoll、Windows 的 IOCP，你会发现它们虽然实现方式不同，但都围绕着同一个目标展开：

把等待交给系统，把 CPU 留给真正有价值的工作。

这也是为什么现代浏览器、服务器和高性能网络框架，越来越倾向于采用异步非阻塞的架构设计。