深入学习 io_uring（一）：从原理到第一个异步程序
系列导航：入门篇 | 进阶篇 | 实战篇 引言：epoll 之后，还能更快吗？ 假设你用 epoll 写了一个高并发 TCP 服务器，性能已经不错——C10K 问题解决了。但当你把连接数推到 C1M（百万级） 时： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 epoll 的瓶颈： 用户态 内核态 │ │ │ epoll_wait() │ ├───────系统调用─────────────→│ ← 每次至少一次上下文切换 │ │ │ 返回就绪的 fd 列表 │ │←───────────────────────────┤ │ │ │ recv(fd_1, buf, ...) │ ├───────系统调用─────────────→│ ← 每个 fd 又一次系统调用！ │ │ │ send(fd_1, resp, ...) │ ├───────系统调用─────────────→│ ← 再一次！ │ │ │ recv(fd_2, buf, ...) │ ├───────系统调用─────────────→│ ← N 个连接 = 2N+ 次系统调用 问题：epoll 只解决了"哪些 fd 就绪"的问题，每次 I/O 操作仍然需要独立的系统调用。百万连接下，系统调用的开销成为主要瓶颈——上下文切换、数据拷贝、内核锁竞争。 ...