1. 异步网络编程导论

要理解异步网络编程，最有效的入口不是先背 API，而是先看清一个事实：网络 I/O 的耗时并不主要发生在 CPU 计算上，而是发生在“等待”上。等待对端发送数据、等待内核缓冲区可读、等待网卡把数据发出去。传统阻塞 I/O 把这段时间直接浪费在“线程挂起”上，而异步编程的全部努力，本质上都是在回答同一个问题——如何用更少的线程，同时照看更多的连接。

一、阻塞 I/O 的代价：一个连接一个线程

在阻塞模型下，服务端典型写法是 accept() 得到一个连接后，把它交给一个线程，线程调用 recv() 读取数据。如果对端暂时没有数据，recv() 不会返回，线程被操作系统挂起，直到数据到达。这个模型直观、易调试，但代价随连接数线性增长。

假设每个线程栈占 1 MB 虚拟内存，一台机器要支撑 1 万个并发连接，仅线程栈就是约 10 GB 的地址空间，再加上线程上下文切换开销。更关键的是，这些线程绝大多数时间处于“可运行但无事可做”的等待状态，CPU 利用率极低。这就是经典的 C10K 问题：不是机器算不动，而是线程模型撑不住。

二、非阻塞 I/O 与就绪通知

非阻塞 I/O 的第一步，是把文件描述符设置为非阻塞模式。此时 recv() 若没有数据，会立即返回 EAGAIN 或 EWOULDBLOCK，而不是挂起线程。但仅仅“不阻塞”还不够——如果程序不停地轮询所有连接，CPU 会被空转烧满。真正让非阻塞 I/O 可用的是多路复用：由内核统一监视一批描述符，只把“已经就绪”的那些返回给应用。

从 select、poll 到 epoll（Linux）、kqueue（BSD/macOS）、IOCP（Windows），多路复用机制不断演进。epoll 的关键改进是：它不再每次调用都遍历全部描述符，而是用红黑树维护关注集合、用就绪链表返回活跃事件，因此监视 1 万个连接时，每次只处理真正有事件的那几个，复杂度与活跃连接数相关，而非总连接数。

三、事件驱动模型与事件循环

有了就绪通知，程序结构也随之改变。事件驱动模型的核心是一个事件循环：它反复调用多路复用接口，取出就绪事件，分派给对应的处理函数（回调），处理完再回到循环。整个进程通常只有少量线程，却可以管理成千上万个连接。

事件循环要处理的事件类型通常包括：新连接到达（可读事件）、已有连接有数据可读、连接可写、连接关闭或出错。每个连接被抽象成一个状态对象，保存它的缓冲区、解析进度和回调。这样，一个连接的“生命周期”被拆成多个由事件触发的片段，而不是一段连续的阻塞代码。

四、Reactor 与 Proactor：谁负责读写

事件驱动有两种经典模式，区别在于“谁真正执行 I/O 读写”。

Reactor 模式：内核只通知“就绪”，应用自己调用 recv/send 完成读写。它是同步非阻塞 I/O 的封装，Linux 上的 epoll、Java NIO、Netty、Redis 都属于这一类。结构上通常有一个主 Reactor 负责 accept，多个从 Reactor 负责已连接套接字的读写，再由工作线程池处理业务逻辑。

Proactor 模式：应用只发起异步 I/O 请求（如 aio_read），内核完成数据搬运后再通知“已完成”，应用直接处理结果。Windows IOCP 是典型代表。它省去了应用层的就绪判断，但编程模型更复杂，且在不同平台上的支持程度不一。

可以这样记：Reactor 是“你告诉我能读了，我自己读”；Proactor 是“你帮我读完，再告诉我结果”。

五、异步编程的核心价值与典型场景

异步编程的价值可以归纳为三点：高并发下的低资源占用（少量线程支撑海量连接）、高吞吐与低延迟（避免线程切换和锁竞争）、更好的可伸缩性（连接数增长时性能衰减平缓）。

它最适合 I/O 密集、连接数多、单次请求计算量不大的场景，例如：即时通讯与推送服务、API 网关与反向代理、实时行情与消息队列、爬虫与长连接网关。反之，如果是 CPU 密集型计算，异步并不会带来收益，反而增加复杂度。

六、一张图看清演进关系

下面这张图把阻塞 I/O、非阻塞轮询、多路复用、Reactor 与 Proactor 放在同一条演进链上，并标出每一步“谁在等待、谁在读写”，便于对照理解。

把这张图记牢，后续学习协程、事件循环、连接池和背压时，都能回到同一个判断标准：当前这个等待，是被线程承担，还是被事件循环承担。前者决定资源上限，后者决定并发规模。