在高性能网络编程的面试中，“Reactor 与 Proactor 模式的区别及 Linux 下的落地方式”是一道高频题。很多候选人能背出“Reactor 同步非阻塞、Proactor 异步非阻塞”的结论，但一旦追问“Linux 上到底怎么实现 Proactor”“epoll 属于哪一种”，回答就开始含糊。本文从面试实战角度，把这两个模式的本质、Linux 下的可落地路径以及常见误区讲清楚。
一、先厘清本质：谁负责读写数据
两种模式的核心差异只有一个：真正的 I/O 读写操作由谁完成。
- Reactor：应用注册感兴趣的事件（可读/可写），事件到来时由事件循环通知应用，应用自己调用 read/write 完成数据搬运。所以 Reactor 是“同步”的——同步指的是 I/O 操作本身在应用线程中同步执行。
- Proactor：应用发起一个异步 I/O 请求，内核负责把数据读入用户缓冲区（或从用户缓冲区写出），完成后通知应用。应用拿到的是“已经完成的结果”，所以是“异步”的。
一句话记忆：Reactor 通知你“可以读了”，Proactor 通知你“已经读完了”。
二、Reactor 在 Linux 下的落地
Linux 是 Reactor 模式的主场，因为 epoll 天生就是为“就绪通知”设计的。
1. 核心组件
- Reactor（事件循环）：由 epoll_wait 驱动，负责监听所有注册的 fd。
- Handler（事件处理器）：每个 fd 绑定一个回调，处理可读/可写事件。
- Acceptor：监听 socket 上的连接事件，accept 后把新连接注册到 epoll。
2. 典型代码骨架
// 伪代码，突出结构
int epfd = epoll_create1(0);
// 注册 listenfd 的 EPOLLIN
epoll_ctl(epfd, EPOLL_CTL_ADD, listenfd, &ev);
while (1) {
int n = epoll_wait(epfd, events, MAX, -1);
for (int i = 0; i < n; i++) {
if (events[i].data.fd == listenfd) {
int connfd = accept(listenfd, ...);
set_nonblocking(connfd);
epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev); // 注册 EPOLLIN
} else {
// 应用自己 read，读完再处理
int n = read(events[i].data.fd, buf, sizeof(buf));
// ... 业务处理
}
}
}
注意关键点：read 是在应用线程里同步调用的，这正是 Reactor 的“同步”含义。
3. 三种演进形态（面试加分项）
- 单 Reactor 单线程：Redis 早期模型，简单但无法利用多核。
- 单 Reactor 多线程：Reactor 只负责事件分发，业务处理丢给线程池（如 Memcached）。
- 主从 Reactor 多线程：mainReactor 负责 accept，subReactor 负责读写，Netty 主从模型即此。Linux 下常用多个 epoll 实例 + SO_REUSEPORT 实现多 Reactor。
三、Proactor 在 Linux 下的落地难题
这是面试最容易翻车的地方。严格意义上的 Proactor 需要内核提供真正的异步 I/O 接口，而 Linux 长期缺乏成熟的异步 I/O 支持。
1. Windows 的 IOCP 才是“正统” Proactor
Windows 的 IOCP（I/O Completion Port）是标准 Proactor：应用投递 WSARecv，内核完成数据拷贝后投递完成通知。这也是为什么很多讲 Proactor 的教材以 IOCP 为例。
2. Linux 的困境与两条落地路径
路径一：用 epoll 模拟 Proactor（最常用）
做法是：应用层封装一个“异步读”接口，内部仍然用 epoll 监听可读事件，但由框架（而非业务代码）在事件触发后完成 read，再把读好的数据回调给业务。对业务而言，它“发起请求—等回调拿数据”，看起来就是 Proactor。
Boost.Asio 在 Linux 上正是这么做的：它的 async_read 底层是 Reactor（epoll），但通过框架代劳读写，对外呈现 Proactor 语义。所以有句话叫 “Asio 在 Windows 上是真 Proactor，在 Linux 上是模拟 Proactor”。
路径二：使用真正的异步 I/O 接口
- POSIX AIO（glibc aio_*）：实现质量差，底层多用线程模拟，性能不佳，基本不用。
- Linux Native AIO（io_submit/io_getevents）：只支持
O_DIRECT的直接 I/O，对普通文件/网络 socket 支持有限，且不支持 socket，难以用于网络服务器。 - io_uring（5.1+ 内核）：这是 Linux 真正意义上的异步 I/O 革命。通过提交队列（SQ）和完成队列（CQ）共享内存，应用投递请求、内核完成后写 CQE，无需系统调用即可收割结果。它既能做真正的 Proactor，也能高效实现 Reactor。目前已成为高性能服务器的新宠（如部分版本的 Nginx、ScyllaDB 已在探索）。
面试时若被问“Linux 怎么实现 Proactor”，标准答案是：epoll 是 Reactor 的基础，Linux 原生缺乏成熟异步 I/O，通常用 epoll + 框架代劳读写来模拟 Proactor；真正的 Proactor 可依赖 io_uring。
四、一张表说清区别
| 维度 | Reactor | Proactor |
|---|---|---|
| I/O 操作执行者 | 应用自己 | 内核/框架 |
| 通知语义 | 就绪（可读/可写） | 完成（已读/已写） |
| Linux 代表 | epoll、select、poll | io_uring、Asio 模拟 |
| Windows 代表 | WSAEventSelect | IOCP |
| 编程复杂度 | 较低，需自己管理读写 | 较高，但业务逻辑更简洁 |
五、常见面试误区
- “epoll 是 Proactor”：错。epoll 只通知就绪，读写仍由应用完成，是典型 Reactor。
- “非阻塞 I/O 就是异步 I/O”：错。非阻塞是 Reactor 的基础，异步是 Proactor 的前提，两者不同层次。
- “Reactor 性能一定不如 Proactor”：不一定。在 Linux 上，精心实现的 Reactor（如 epoll ET 模式）性能极高，Proactor 的优势更多体现在编程模型而非绝对性能。
- “Linux 没有 Proactor”：不严谨。有 io_uring 后，Linux 已具备实现 Proactor 的底层能力。
六、总结
回答这道面试题，记住三层递进：第一层讲清“谁负责读写”的本质差异；第二层说明 Linux 上 Reactor 靠 epoll 落地、Proactor 靠模拟或 io_uring 落地；第三层点出 epoll 是 Reactor、io_uring 才是 Linux 异步 I/O 的未来。 能把 io_uring 和 Asio 的模拟机制讲出来，基本就能从“背概念”的候选人中脱颖而出。
未经允许不得转载：任鹏个人博客 » Linux 面试题：Reactor 与 Proactor 模式在 Linux 下如何落地
