聊网络编程基本绕不开 select、poll、epoll 这三个名字。只要你写过 TCP 服务器、处理过并发连接大概率会被这三个东西支配过。所谓 IO 多路复用说白了就是一个线程守住很多个文件描述符哪个来数据了就处理哪个这样服务器就不需要为每个连接开一个线程。今天这篇就好好捋一遍这三个系统调用分别是怎么设计的各自解决了什么问题坑藏在哪里以及到了现在你写代码时到底该选谁。“多路复用”四个字翻译成人话就是一堆连接共用一个查询口内核告诉你有哪个连接可读了你就去处理哪个。没有这层抽象你要么用阻塞 IO 一个线程伺候一个连接要么用非阻塞 IO 自己循环去轮询每个 socket前者扛不住上万连接后者在连接数上去之后 CPU 基本全浪费在无效的系统调用上。select、poll、epoll 的出现就是为了把这些事从用户态兜到内核态由内核帮你盯着所有 fd等事件发生了再通知你。这里先说个题外话给自己提个醒网上搜“select”的时候你会看到一堆不相关的东西。比如 SQL 里的 SELECT 查询语句这是数据库语法跟本文没有关系再比如 Honey Select 2 这种游戏、Modbus Poll 这种工业通讯调试工具甚至 IntelliJ IDEA 里那个“Select Opened File”按钮都只是恰好碰上了同名关键词别被搜索标题带偏。今天讨论的是 Linux/Unix 系统调用级别的 select、poll、epoll属于网络编程的硬核范畴。1. 从阻塞 IO 说起为什么需要多路复用1.1 服务端并发模型的演进从一连接一线程到事件驱动先看最原始的阻塞 IO 模型。一个 socket 创建好之后默认就是阻塞模式recv()调用会一直挂起直到内核缓冲区里有数据可读。于是早期服务端的写法通常就是主线程accept()之后创建一个新线程让这个线程去处理那个连接的recv()。你在本地写个小 demo 没问题几十个连接也能凑合但到了几千个连接线程上下文切换的开销就能把 CPU 拖垮每个线程还要占栈空间内存也随之吃紧。所以后来大家都转投非阻塞 IO把 socket 设置成O_NONBLOCK然后一个线程循环遍历所有 fd挨个去read()试探有数据就读没数据就返回EAGAIN。这样确实省了线程但每次循环你都要对几千个 fd 各做一次read()系统调用绝大多数是无效试探用户态和内核态来回切CPU 照样被白白吃掉。select、poll、epoll 就是在这样的背景下登场的它们让你一次性地把“我要关注的 fd 列表”和“我关心的事件”交给内核内核批量监听然后返回一个“哪些 fd 有事件”的结果你再针对性地去处理。从“挨个主动问”变成“有事件才通知”这才是多路复用的本质。1.2 机制设计的核心差异事件通知而非被动轮询我更喜欢把这个机制类比成你不是每分钟挨个打电话问所有朋友吃了没而是把他们拉进一个群谁要聊就自己冒泡你只看冒泡的人就行。不过这里有个细节需要注意select 和 poll 本质上还是“群里的每个人都得回应你一下”——内核会把整个 fd 集合从头到尾扫一遍告诉你有几个就绪但不告诉你具体是第几个你得自己再遍历一遍去比对。真正做到了“谁冒泡我处理谁”的是 epoll。这个区别是整个文章后续所有讨论的核心线索。2. select最朴素的多路复用方案2.1 select API 与 fd_set 的真相select 的原型长这样int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);参数解释起来不复杂nfds是你要监听的最大文件描述符编号加一readfds是关心“可读”的 fd 集合writefds关心“可写”exceptfds关心异常timeout是超时时间填 NULL 就是永久阻塞。返回时内核会修改这三个 fd_set 的内容把“没有事件的 fd”对应的位清掉留下的就是真正就绪的 fd。fd_set的本质是位图每一位对应一个 fd。常用操作是FD_ZERO清零、FD_SET把某个 fd 对应的位置 1、FD_ISSET查询某一位是否为 1、FD_CLR清除某一位。这个位图的大小受FD_SETSIZE限制在 Linux 上默认是 1024也就是说 select 一个进程最多监听 1024 个 fd就这一个限制就决定了它不可能支撑高并发场景。还有一个反直觉的细节timeout参数在 Linux 上是不安全的select 返回之后内核会修改timeval的值把它改成剩余时间。所以如果你在一个循环里反复调用 select每次都必须在调用前重新初始化timeout。我早期写循环监听时就踩过这个坑第一次超时设置 10 秒select 返回后第二次进来timeout 已经被内核改成了几乎为 0结果整个服务变成忙轮询CPU 直接飙满。2.2 select 的三大硬伤数量、拷贝、线性扫描select 的第一个硬伤就是 fd 数量上限。FD_SETSIZE默认 1024你要管的连接超过这个数要么改内核重新编译在 Linux 上可以通过修改__FD_SETSIZE做到但生产环境没人愿意这么干要么就得自己分多个进程、多个 select 并行复杂度一下子上来了。第二个硬伤是拷贝开销。每次调用 select内核都要把三个 fd_set 从用户态拷贝进来返回时再拷贝回去。连接少的时候感觉不到但 fd 集合一大光拷贝就吃 CPU。而且注意这里不是“拷贝一次”是每次调用都拷select 返回后你还得自己重新把要监听的 fd 一个一个FD_SET进去因为内核会把没就绪的位清掉。这个“每次都要重新设置”的写法不仅啰嗦还容易漏。第三个硬伤是线性扫描。内核拿到 fd_set 之后实际上是从 0 扫描到nfds-1逐个检查每个 fd 是否有事件。假设你有 1000 个连接但只有 3 个活跃内核照样扫 1000 个位用户态拿到结果后又要遍历一遍 fd_set 找出那 3 个就绪的。这就是 O(n) 的代价连接越多浪费越明显。select 适合的场景是 fd 数量少、活跃比例高的场合比如几十个连接的小型服务能用也够用。3. poll修复了一部分但骨架没变3.1 poll API 与事件描述结构告别位图走向数组poll 的出现就是为了解决 select“1024 上限”和“位图操作繁琐”两个问题。它的原型是int poll(struct pollfd *fds, nfds_t nfds, int timeout); struct pollfd { int fd; /* 要监听的 fd */ short events; /* 关心的事件POLLIN / POLLOUT 等 */ short revents; /* 返回时就绪的事件 */ };和 select 最大的不同是poll 用pollfd数组来代替fd_set位图每个 fd 对应数组里的一项。你把这个数组交给内核内核检查每个pollfd的events然后把就绪的事件写进revents。由于events和revents是分开的内核不会去修改你设置的events所以 poll 不需要像 select 那样每次调用前重新设置整个监听集合。这一点在日常编码体验上是实打实的改进。3.2 poll 相比 select 的改进与没改进的地方改进点很明确第一没有 1024 个 fd 的上限了实际受限于系统RLIMIT_NOFILE单进程能打开多少 fd 由ulimit决定现代系统普遍可以调到几十万第二事件按数组下标组织可读性比位图好第三revents字段能区分POLLERR、POLLHUP、POLLNVAL这类异常事件select 当年只能靠exceptfds勉强处理poll 的表达力明显更强。但是 poll 没解决的核心问题也很明显。首先它依然是每次调用都要把整个pollfd数组从用户态拷到内核态返回前再拷回来。这个拷贝的量级和 select 差不多只是从位图变成了结构体数组体积甚至更大。其次内核依然是线性扫描拿着数组从头到尾检查每个 fd 的状态时间复杂度还是 O(n)。第三返回之后用户态还是得遍历整个数组看哪些revents非零才知道哪些 fd 就绪了。也就是说poll 只是把 fd 数量限制给解开了但“拷贝 全量扫描”这个性能瓶颈一点没碰。我在实际项目里用过 poll 的阶段体验是“比 select 舒服但不敢有大期待”。适合中等连接数、事件分布相对均匀的场景。另外有个细节poll 的超时参数timeout单位是毫秒负数表示永久阻塞0 表示立即返回这个和 select 的timeval结构体比起来反而更好用不用每次初始化两次字段。4. epollLinux 系统下的高效实践4.1 三个 API 与两种触发模式从全量扫描到回调通知epoll 是 Linux 2.6 之后引入的方案专门为高并发设计。它不像 select/poll 那样只有一个函数而是由三个系统调用配合完成int epoll_create(int size); // 创建 epoll 实例 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 注册/修改/删除 fd int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); // 等待事件就绪epoll_create创建一个 epoll 实例返回一个文件描述符。注意这里的size参数在 Linux 2.6.8 之后其实被忽略了内核会按需扩展但保留这个参数是为了兼容老代码。epoll_ctl负责往实例里注册 fdop 可以是EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL。epoll_wait则是阻塞等待事件就绪的 fd 会写到传入的events数组里maxevents告诉内核这次最多返回多少个。epoll 和 select/poll 最本质的区别在于它在内核里维护了两个关键数据结构一个红黑树用来存放所有注册进来的 fd一个就绪链表用来挂接真正有事件发生的 fd。当你调用epoll_ctl添加 fd 时内核会把该 fd 注册进红黑树并给这个 fd 挂一个回调函数。一旦这个 fd 上有数据到达设备驱动层触发回调内核就把这个 fd 直接挂到就绪链表上。等到你调用epoll_wait时内核只需要把就绪链表里的 fd 拷贝到用户态的events数组然后返回数量。这个机制做到了两件事注册 fd 是 O(log n) 的红黑树操作获取就绪 fd 是 O(1) 的直接取链表头。它完全不关心你到底注册了多少个 fd只关心“此刻有多少个 fd 真正就绪了”。4.2 为什么 epoll 在大量连接下这么能打红黑树 就绪链表 回调网上有个流传很广的说法是“epoll 通过 mmap 共享内存来避免拷贝”。严格来说epoll 官方没有依赖 mmap 来实现用户态和内核态的事件传递它靠的是把就绪链表整体拷贝给用户态。但关键在于它拷贝的是“就绪的那一小撮”而不是 select/poll 那种“全部 fd 集合”。这就把一个很贵的全量拷贝问题变成了一个便宜的增量拷贝问题。连接越多、活跃比例越低的场景epoll 的优势越明显。再补充一个 epoll_ctl 的使用细节struct epoll_event里的events字段可以填EPOLLIN可读、EPOLLOUT可写、EPOLLRDHUP对端关闭、EPOLLERR、EPOLLHUP还有两个很关键的标志——EPOLLET和EPOLLONESHOT。EPOLLET表示把该 fd 设为边缘触发模式EPOLLONESHOT表示某个 fd 在触发一次事件后自动从监听列表里摘除防止多线程下同一个 fd 被多个线程同时处理。就绪链表这个设计还有一层好处它天然支持了“只遍历活跃 fd”的迭代方式。select 和 poll 返回后你不得不遍历整个集合才能找到就绪 fd而 epoll 返回的events数组本身就是就绪列表的快照下标即事件直接for (i 0; i n; i)处理就行不需要再做第二次过滤。4.3 LT 与 ET 模式理解不够就会出事的经典场景epoll 有两种触发模式这里必须展开讲清楚因为这是生产环境里最容易翻车的地方。水平触发LTLevel Triggered是默认模式。它的行为是只要 fd 的缓冲区里还有数据没被读完epoll_wait就会不断通知你。你读了一半剩下的一半还在缓冲区里下一次epoll_wait还会把这个 fd 给你。这种模式下即使你用了阻塞 fd、或者一次性没读完问题也不大最多就是多等一轮再读。好处是代码好写不容易漏事件坏处是如果你明明处理不过来内核还反复提醒你会造成一定的无效唤醒。边缘触发ETEdge Triggered只在状态变化时通知一次。比如缓冲区从“空”变成“有数据”的这一刻内核通知你一次如果你这次没把数据读完对不起内核不会因为“还有数据”再通知你一次除非有新的数据再进来。所以 ET 模式强制要求你必须把 fd 设置成非阻塞然后在可读事件里循环read()一直读到返回EAGAIN为止否则必然丢数据。这个“读到 EAGAIN 才算完”的写法是 ET 模式的最核心实践。我见过不少同事在 ET 模式下跌倒读了一次就 break结果客户端发了一个超过内核缓冲区的包数据被截断了服务端却再也没收到那个 fd 的通知等于这个连接上的请求永远丢失。排查这类问题往往特别费劲因为它不是每次都复现而是“大包才出问题”。所以我的建议是如果你不是对 epoll 非常熟悉优先用 LTET 能给你带来更少的无效唤醒但它要求你严格管控每个 fd 的读写循环代价是代码复杂度和心智负担都明显上升。5. 三个方案横向对比与选型依据5.1 核心差异速查一张表记住三者的本质区别先把三者的核心技术差异拉成一张表方便你平时查阅对比维度selectpollepoll最大 fd 数量FD_SETSIZE默认 1024受系统进程 fd 上限限制受系统进程 fd 上限限制可支持几十万事件存储结构fd_set 位图pollfd 数组内核红黑树 就绪链表用户态到内核态拷贝每次调用全量拷贝三个集合每次调用全量拷贝数组无全量拷贝只拷就绪事件内核查找就绪 fd 方式线性扫描 0 到 nfds-1线性扫描整个数组回调机制直接摘取就绪链表触发模式仅水平触发仅水平触发水平触发(LT)和边缘触发(ET)就绪结果获取遍历整个 fd_set遍历整个 pollfd 数组直接遍历返回的就绪 events 数组平台支持几乎所有平台POSIX 标准多数平台支持Linux 专属时间复杂度注册 O(1)就绪检查 O(n)注册 O(1)就绪检查 O(n)注册 O(log n)就绪检查 O(1)这张表里最扎眼的一行就是“用户态到内核态拷贝”和“内核查找方式”这两处的差异直接决定了三者在 1 万连接下的表现差距。select 和 poll 是“我关心所有 fd从头到尾查一遍”epoll 是“我关心所有 fd但只回答就绪的那些”。一个是全量遍历一个是事件驱动本质上不是同一个物种。5.2 实际选型建议什么场景用 select什么场景直接上 epoll选型这件事不能只看性能还得看工程约束。如果你的代码要跨 Windows 和 Linux 跑那 Windows 上根本没有真正高效的 epoll 等价物虽然有 IOCP但模型完全不同这时候你多半只能选择 select因为winsock.h里就有select跨平台成本最低。很多老牌的跨平台网络库底层在 Windows 上用 select在 Linux 上用 epoll就是这么干的。如果你的目标是 Linux 下的高并发服务比如常见的网关、消息推送、链接跟踪服务不要犹豫直接用 epoll。它的性能优势和编程模型都是为大规模连接设计的。具体来说epoll_wait的maxevents参数配合动态扩容的接收数组可以轻易支撑几十万连接。还有个折中思路如果你不想手搓 epoll也可以直接用 libevent、libuv、Netty 这类封装好的事件库它们底层会帮你选最优的多路复用器你只暴露业务回调。不过我还是建议每个写网络编程的人都亲手用 epoll 写一个 echo server哪怕只是几百行代码因为这个过程里踩过的 ET 坑、理解过的回调机制是后面排查线上问题的重要直觉来源。6. 工程实战中的高频问题与排查笔记6.1 那些年我踩过的坑惊群、fd 耗尽、timeout 被修改先说“惊群”。多线程模型下如果多个线程同时调用epoll_wait监听同一个 epoll 实例当某个 fd 就绪时内核可能会唤醒多个线程但最终只有一个线程能处理这个 fd其他线程醒来发现没事可做又睡回去白白消费 CPU。这个问题在内核 4.5 之前没有完美解法大家普遍的做法是只用主线程调epoll_wait拿到就绪 fd 列表后再分发给工作线程。4.5 之后内核加入了EPOLLEXCLUSIVE标志可以在epoll_ctl注册 fd 时加上让内核保证只唤醒一个等待线程直接根治惊群。如果你的内核版本支持强烈建议加上。然后是 fd 耗尽。select 受FD_SETSIZE限制poll 和 epoll 理论上只受单进程文件描述符上限约束。但生产环境经常出现“连接数明明没到瓶颈服务却开始报Too many open files”这就是ulimit -n没调。排查思路很简单ulimit -n看软限制cat /proc/pid/limits看进程实际限制如果太小用ulimit -n 65535或者改/etc/security/limits.conf。我见过一个走了半天的案例最后发现就是nofile默认 1024服务一启动就撞墙。还有个老生常谈的问题就是 select 的timeout会被内核修改导致循环调用时超时时间错乱。如果你在写跨平台代码必须用 select记住每次进入循环都重新初始化struct timeval。poll 和 epoll 没有这个问题timeout只是入参不会被修改。6.2 三种明明就绪却没返回的诡异场景有一种情况很迷惑poll返回大于 0但你遍历pollfd数组时发现对应 fd 的revents是 0。这通常不是 bug而是内核把某些事件放在了你没监听的事件类型里。比如 fd 上发生了POLLERR或POLLHUP但你没在events里设置这些位内核依然会把它们反映到revents。遍历时你只检查POLLIN就会漏掉这些信号。所以在写 poll 的事件处理时建议把POLLERR | POLLHUP | POLLNVAL单独拉出来兜底该关的关该重连的重连。epoll 的类似坑是拿到EPOLLIN事件后去read()如果读出来 0 字节说明对端已经关闭连接这个 fd 应当从 epoll 实例中移除并 close不能继续留着急等下一个EPOLLIN。很多新人在这里不判断read()的返回值导致 fd 泄漏连接数一点一点涨上去直到资源耗尽。还有一个小细节EPOLLRDHUP这个标志在 TCP 对端关闭写端时会出现如果你用长连接做心跳检测可以用它辅助判断对端是不是已经掉线比等EPOLLIN读到 0 更及时。症状可能原因排查方向CPU 飙高但连接数不多非阻塞 fd 忙轮询或 timeout 被 select 改成了 0检查循环是否每次重新初始化 timeout大包请求经常丢一半ET 模式下一次 read 就 break没读到 EAGAIN检查是否使用 ETread 循环是否完整单进程最多只能接受 1024 个连接受 FD_SETSIZE 或 ulimit 限制ulimit -n调大或改用 poll/epollepoll 返回事件但 read 出 0 字节对端已关闭未及时 close fd处理返回值0 字节时必须清理 fd多线程同时被唤醒epoll 惊群内核 4.5 使用 EPOLLEXCLUSIVE莫名Too many open filesfd 泄漏检查所有 close 路径结合 lsof 分析6.3 调优技巧几个我自己常用的经验数值读epoll_wait返回的events数组时maxevents值别拍脑袋填。填太小一次能处理的事件就少高流量时循环次数变多填太大每次拷贝的epoll_event结构体数组本身也有内存开销。我一般取“预计同时就绪峰值”的两倍左右实践中取 64 到 256 之间比较稳妥。当然这只是经验值如果你的连接数到了百万级别需要压测校准。关于 LT 和 ET 的取舍我的个人倾向是默认 LT除非你明确知道业务需要减少无效唤醒。真正的高性能服务ET 非阻塞 fd 应用层缓冲区是标配但这是合理解释“为什么循环读直到 EAGAIN”之后才能上手的。很多框架帮你封装好了但如果你在裸写 epoll务必自己吃透 ET 的语义再上生产。7. 写在最后一份真实的工作经验清单这篇文章偏偏绕回来讲的全是服务端网络编程里最基础又最容易被忽略的东西。我的实际体会是多数性能问题都不是“技术不够新”而是“基础模型没吃透”。你用 select 扛 1 万连接理所当然会崩你分不清 LT 和 ET写出来的服务器在大包场景下必然丢数据。这些不是玄学是机制。最后再分享一个小技巧如果你在写一个新的网络服务先在文档里把“选型理由”写清楚——为什么用 select为什么换成 epoll为什么选 ET。写清楚这个比贴一堆代码更能帮你团队减少日后的踩坑。代码可以重构模型错了要改的方向可大得多。