异步模型解密

先看清"阻塞"到底卡在哪

上一篇说"线程等待 IO 时被白白占用".这个"等待"具体发生在哪?看一次普通的阻塞读:

let mut buf = [0u8; 1024];
let n = stream.read(&mut buf)?; // 数据没来之前,这一行不返回

read 是一个系统调用.如果此刻网卡还没收到数据,操作系统会把发起调用的线程置为"睡眠",直到数据到达才唤醒它.这段睡眠期间,线程完全无事可做,却仍占着资源.

阻塞读的时间线:
  线程 ──调用 read()──▶ [睡眠,等数据............] ──数据到──▶ 返回 n 字节
                        └─ 这段时间线程被冻结,什么也干不了 ─┘

第一块拼图:非阻塞 IO

操作系统其实提供了另一种模式:把文件描述符设为非阻塞(non-blocking).这时调用 read,如果数据还没来,它不睡眠,而是立刻返回一个特殊错误 WouldBlock("现在还没好,待会儿再来").

非阻塞 read 的两种结果:

1. 数据已就绪 → 立刻返回读到的字节
2. 数据没就绪 → 立刻返回 WouldBlock 错误(不睡眠!)

这就解开了线程的枷锁:线程发起读,拿到 WouldBlock,转身就能去干别的事,不必卡在原地.

第二块拼图:就绪通知(epoll)

解决忙轮询的,是操作系统提供的IO 多路复用机制:Linux 上是 epoll,macOS 上是 kqueue,Windows 上是 IOCP.思路统一:

把成千上万个连接一次性登记给操作系统,然后调用一个"等待"接口.这个接口会睡眠,但它替我们监视所有连接--只要其中任意一个就绪,它就返回,并告诉具体是哪些就绪了.

忙轮询(坏)                      epoll(好)
  ──────────                      ──────────
  while True:                      把 1 万个 fd 登记给 epoll
    for fd in 10000 个连接:        epoll_wait()  ← 睡眠,不耗 CPU
      试着 read(fd)  ← CPU 空转       └─ 任意 fd 就绪即返回就绪列表
                                    只处理真正就绪的那几个

第三块拼图:事件循环

把前两块拼起来,就得到异步的引擎--事件循环(event loop).它的骨架是这样一个循环:

事件循环(伪代码):
  loop {
      就绪列表 = epoll_wait()          // 睡眠,直到有 IO 就绪
      for 每个就绪的 IO:
          唤醒等待它的任务              // 让对应任务继续往下跑
          运行该任务,直到它再次因 IO 等待而让出
  }

整个异步系统就围着这个循环转:任务要么在跑(有 CPU 活儿可干),要么在等(登记给 epoll 后让出).没有任何线程因"干等某个 IO"而被冻结.一个事件循环线程,就能驱动海量任务.

Go runtime 藏起来的就是这套

现在回看 Go.当写下这段再普通不过的代码:

n, err := conn.Read(buf) // 看起来是"阻塞"的

它看起来阻塞,但 Go runtime 在底层做的,正是本篇这套机制:它把 conn 设为非阻塞,数据没来时把这个 goroutine 挂起,登记到 netpoller(Go 对 epoll/kqueue 的封装),让出线程去跑别的 goroutine;数据到了,netpoller 通知 runtime 唤醒该 goroutine.

一张全景图

异步在不同层次的对应关系,先建立全局印象,后续逐篇填充细节: