如果你试过用Python写一个需要同时维护几千甚至几万TCP连接的服务，大概率会遇到这样的场景：连接数一上去，CPU明明不高，请求却越来越慢，甚至大量超时。我在好几台开发机上反复折腾过这类问题，最后的解法都落在同一个点上：Linux的epoll。epoll是Linux内核提供的高并发I/O多路复用机制，也是目前服务端网络编程中最核心的基础能力之一。这篇文章就用Python标准库里select模块的epoll封装，把它的原理、API、完整实现和常见调试思路一次讲清楚。适合下面几类读者：写长连接网关、IM、消息推送的人；被select或线程模型性能瓶颈卡住的开发者；想真正理解事件驱动服务器怎么工作的人。
1. 瓶颈都出在哪：从阻塞I/O到select/poll
1.1 线程模型在高并发下撑不住的本质原因
先看最直观的做法：每一个客户端连接开一个线程，客户端有数据就recv，没数据就等着。这个模型的成本主要由三部分组成：线程本身的内存开销、线程切换的CPU开销、以及阻塞式recv带来的资源闲置。一个常规线程栈默认在几MB到几十MB不等，8000个线程就能把普通服务器内存吃紧；CPU调度器面对几千个可运行线程，光上下文切换就能把系统压垮，业务还没干活，时间全花在切换上了。
更要命的是阻塞式recv，它会让你这个线程干坐在那里等数据，期间什么业务都做不了。你可能会说，把socket设置成非阻塞，用一个线程去轮询所有连接不就行了？能行，但本质是浪费：每轮循环都要把几万个连接挨个问一遍，绝大多数连接并没有数据，白白消耗CPU。早期很多服务就是靠线程+轮询硬撑的，连接规模一旦过万，这种模式就明显顶不住了。
线程模型并不是完全不能用，但用它直接扛上万连接，确实不划算。高并发服务真正需要的，是让少量线程管理海量连接，一个线程在一个时刻只处理那些“已经就绪”的连接，这就引出I/O多路复用。所谓就绪，就是一个连接上确实发生了可读、可写或者异常事件，而不是让程序凭空猜测。
1.2 select和poll为什么不适合大连接规模
epoll之前最常用的多路复用方案是select和poll。select把文件描述符集合传给内核，内核通过遍历找到有事件的fd，返回后再由应用层遍历一遍fd集合拿到结果。它的fd数量限制受FD_SETSIZE约束，默认1024，要扩大得改内核配置重新编译，非常不友好。poll虽然用链表突破了数量限制，但本质上每次调用还是把整个fd数组从用户态拷到内核态，内核线性扫描一遍，返回后用户层还得再线性扫一遍，复杂度始终是O(n)，连接越多，单次开销越大。
select还有一个容易忽略的隐藏问题：它对活跃连接和空闲连接一视同仁。不管这个fd有多少年没动静，内核每次都要扫到它，应用层拿到的结果集里也包含大量无用的空闲fd。你可以自己加一层数组只遍历活跃fd，但内核那趟扫描躲不掉。所以select/poll在几百个连接时表现还行，超过几千个之后，性能是肉眼可见地往下掉。指望它们扛几万、几十万并发，基本不现实。
1.3 epoll凭什么能扛住几十万连接
epoll的设计思路和select/poll完全不同。它维护一棵红黑树来存放被监控的文件描述符，你通过epoll_ctl注册、修改、删除fd，把这个fd挂上去之后就不用管了，内核会负责跟踪。内核在设备驱动层面注册了回调函数，当某个fd上有事件发生，回调会把对应fd放到一个就绪链表里。等你调用epoll_wait，它直接从这个就绪链表里取事件返回，一次处理多少个就是多少个，不用扫描全部fd。
这个机制带来的直接结果就是：无论你管理多少个连接，内核通知你的事件数量和“活跃连接数”成正比，而不是和“总连接数”成正比。默认上限几万个，调高系统参数后支持几十万连接完全没问题。再加上epoll支持水平触发LT和边缘触发ET两种模式，后者可以进一步减少重复唤醒的次数，这也是它适合高并发场景的关键原因。打个比方，select像是每隔一段时间翻完整个班级通讯录，问每张三有没有事；epoll则是提前登记“谁有事谁举手”，放大镜只看举手的那些人。连接越多，这种差异越明显。
我整理了一个简单对比表，看完就明白三者差别有多大：
| 维度 | select | poll | epoll |
|---|---|---|---|
| fd数量限制 | 默认1024左右 | 无硬性限制 | 受系统全局上限控制 |
| 内核扫描方式 | 全量线性扫描 | 全量线性扫描 | 回调驱动的就绪链表 |
| 用户态/内核态拷贝 | 全量集合拷贝 | 全量集合拷贝 | 仅拷贝就绪事件 |
| 触发模式 | 水平触发 | 水平触发 | 水平触发LT和边缘触发ET |
| 编程复杂度 | 低 | 低 | 略高，状态管理要求严格 |
2. Python里epoll的基本用法与关键细节
2.1 核心API：从epoll实例到事件掩码
Python标准库select模块提供了epoll封装，调用方式比C简单太多。你需要记住四个方法：epoll()创建实例，register()注册fd，modify()修改fd监听的事件，unregister()注销fd，然后通过poll()拿事件。先看一段最基础的初始化代码：
import socket import select # 创建epoll实例 ep = select.epoll() # 注册一个文件描述符及感兴趣的事件 server_fd = listen_sock.fileno() ep.register(server_fd, select.EPOLLIN) # 轮询事件，timeout单位是秒 events = ep.poll(timeout=1.0) for fd, event in events: # fd：就绪的文件描述符 # event：就绪事件掩码 pass # 修改某个fd的监听事件 ep.modify(conn_fd, select.EPOLLIN | select.EPOLLOUT) # 不再关注时注销，避免fd复用后误触发 ep.unregister(conn_fd)epoll()在Linux上是可用的，Windows的select模块没有这个实现，所以Windows环境要么用select，要么别指望直接用这段代码。poll()的timeout有几种常用取值：不传表示永久阻塞直到有事件；传0表示非阻塞立即返回；传正数表示最多等待多少秒。高并发服务里我一般给它0.5到1秒，这样即使一直没有事件，循环体也有机会执行心跳、清理超时连接这些日常维护工作。
事件掩码是位运算组合，最常用的是EPOLLIN（可读）、EPOLLOUT（可写）、EPOLLERR（错误）、EPOLLHUP（对端挂断），边缘触发要额外加EPOLLET。用event & select.EPOLLIN这种方式判断具体事件，不同事件可能同时出现在一个掩码里，别用==比较，KL，这一点后面调bug的时候会体现出来。
2.2 水平触发与边缘触发的区别和选择
这是epoll最容易踩坑的地方。水平触发LT是默认模式，只要fd上有未读完的数据，每次epoll_wait都返回可读；边缘触发ET只在状态变化时通知一次，比如从无数据变成有数据，从不可写变成可写。
对LT来说，你不用一次把数据读得很干净，内核会反复提醒你；对ET来说，你如果没把数据读完，它可能就再也不通知了，应用层就得采用“读到BlockingIOError才停”的循环读法。这也是ET模式下socket必须是非阻塞的硬性原因：如果只有最后一次recv返回EAGAIN而之前一直有数据，你没法靠阻塞方式等到“没数据”的信号，因为阻塞读会一直在那里等着，事件循环就卡死了。
那到底该用哪种？生产里两种模式都有大量使用。网上很多文章说ET性能高，因为它减少内核态重复上报，但代价是应用代码必须更严谨，读漏了就是业务事故。我个人的经验是：如果是设计网关、代理这类追求极致吞吐的中间件，可以用ET，但每个连接的读写逻辑都要按状态机写；如果业务逻辑复杂、想少踩坑，LT足够应付绝大多数场景，而且性能差距并没有想象中大，瓶颈通常不在通知模式上。
这里也给一个简单的选型建议表：
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 网关/代理/长连接转发 | ET | 吞吐优先，事件密集，实时性要求高 |
| 业务后段复杂、协议拆包多 | LT | 容错高，状态管理简单 |
| 新手学习或快速实现 | LT | 先打通流程再优化，避免被细节淹没 |
2.3 非阻塞socket：epoll正确运转的前提
epoll事件通知解决的是“什么时候有数据”，不是“帮你把数据收发完”。如果socket保持阻塞模式，一旦某个fd返回可读，你在事件循环里直接recv，恰好这次要接收的数据没到齐，recv会卡在那里等，整个事件循环就被这一个连接拖住了，其他几千个连接全部遭殃。所以凡是注册到epoll上的socket，监听socket也好、已接受的连接也好，都必须设置setblocking(False)。
主动连接的对端还有一个更容易被忽略的细节：connect()在非阻塞模式下不会立刻成功，而是返回BlockingIOError，你需要把fd注册到EPOLLOUT上，等可写事件后再用getsockopt(SO_ERROR)确认连接是否建立成功。这个细节搞错，客户端连接逻辑就会时好时坏，连接一多必然暴露。
非阻塞socket的读写，一定记得捕获BlockingIOError，它在C语言里对应EAGAIN/EWOULDBLOCK。读的时候收到它说明“当前没有更多数据了”，写的时候收到它说明“发送缓冲区满了，暂时写不下”，需要把剩余数据暂存到自己的发送缓冲区里，等下一次EPOLLOUT事件再继续发。这是我想强调的第一个实操要点，很多第一次写epoll的人都会在这里卡住。
3. 手写一个高并发回声服务器：完整实现与踩坑记录
3.1 代码骨架与服务端初始化
下面直接给出一个用epoll实现的单线程回声服务器，客户端发什么就回什么。代码不长，但它覆盖了epoll服务端开发的核心流程：初始化监听socket、注册事件、事件循环、处理新连接、处理读写、清理关闭。
import socket import select def create_server(host="0.0.0.0", port=9000, backlog=128): srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((host, port)) srv.listen(backlog) srv.setblocking(False) return srv def cleanup(fd, ep, connections, read_bufs, write_bufs): try: ep.unregister(fd) except OSError: pass try: connections[fd].close() except KeyError: pass connections.pop(fd, None) read_bufs.pop(fd, None) write_bufs.pop(fd, None) def main(): srv = create_server() ep = select.epoll() # 注册监听socket的可读事件，有新连接时就会触发 ep.register(srv.fileno(), select.EPOLLIN) connections = {} # fd -> socket read_bufs = {} # fd -> bytes 累积收到的数据 write_bufs = {} # fd -> bytes 待发送的数据 try: while True: events = ep.poll(timeout=0.5) for fd, event in events: if fd == srv.fileno(): # 有新连接到达，循环accept直到暂时没有连接 while True: try: conn, addr = srv.accept() except BlockingIOError: break conn.setblocking(False) connections[conn.fileno()] = conn read_bufs[conn.fileno()] = b"" write_bufs[conn.fileno()] = b"" ep.register(conn.fileno(), select.EPOLLIN | select.EPOLLRDHUP) else: if event & (select.EPOLLERR | select.EPOLLHUP): # 连接出错或挂断，清理 cleanup(fd, ep, connections, read_bufs, write_bufs) elif event & select.EPOLLIN: try: data = connections[fd].recv(65536) except BlockingIOError: continue except ConnectionResetError: cleanup(fd, ep, connections, read_bufs, write_bufs) continue if not data: cleanup(fd, ep, connections, read_bufs, write_bufs) continue # 收数据后追加到发送缓冲区，并改为关注可写事件 write_bufs[fd] += data ep.modify(fd, select.EPOLLIN | select.EPOLLOUT) elif event & select.EPOLLOUT: # 把待发送数据尽量发出去 try: sent = connections[fd].send(write_bufs[fd]) write_bufs[fd] = write_bufs[fd][sent:] except BlockingIOError: pass except ConnectionResetError: cleanup(fd, ep, connections, read_bufs, write_bufs) continue if not write_bufs[fd]: ep.modify(fd, select.EPOLLIN) finally: ep.close() srv.close() if __name__ == "__main__": main()注意代码里我用了EPOLLRDHUP，这是Linux 2.6.17以后提供的一个标志，对端关闭连接时能立刻得到通知，不用等下一次读返回空，省掉一轮事件循环。Python的select模块提供了这个常量，可以直接用。在这个基础上，你还可以给每个连接记录时间戳，定期遍历不活跃连接，按心跳超时关闭，这样空连接不会无限累积占fd。
3.2 为什么事件循环里不要直接阻塞
事件循环的整体逻辑并不复杂，但有一个原则必须贯穿始终：不能在循环体里做任何阻塞操作。除开socket读写要保持非阻塞，注册了epoll wait之后，核心线程的时间是几百个连接共享的，任何一段耗时操作都会被放大成所有连接上的延迟。业务处理如果比较重，应该把它交给线程池或进程池，事件循环只负责收发和简单的协议拆包。
一个常见的反面例子：有人在EPOLLIN事件里直接做正则匹配、查数据库、调用第三方接口，结果一个请求几百毫秒，整个服务在压力测试下全部排队。要记住epoll只解决I/O多路复用这一层，它不解决业务计算慢的问题。耗时操作必须异步化，这也是事件驱动架构里最基本的一条守则。
对于NULL值，读到的可能要区分业务二进制数据还是空消息，但作为thou台服务端，只要tcp对端close，recv返回空数据就要及时清理状态。
3.3 实测效果与关键优化点
代码搭起来后，我在本地开发机做过横向对比：保持一万个连接同时在线，客户端每个连接每秒发一个小包，回声返回基本不出现明显延迟累积；同样的机器上用select版本，到了两三千连接就开始丢包、延迟抖动。这个对比足以说明epoll在管理大规模连接上的价值。当然这个结果很受系统版本、文件句柄上限、内存大小影响，你跑不出来也别慌，重点是同一环境下横向对比。
真要往生产方向走，有几个优化点很关键。第一是调整系统的文件描述符上限，ulimit -n要提到几万甚至更高，否则连接数还没到epoll瓶颈，你先把进程的文件句柄用完了。第二是accept逻辑要写完整，LT模式下其实不用循环到EAGAIN，但循环accept到BlockingIOError是更安全的通用写法，尤其是ET模式下必须这样。第三是定义应用层协议，把TCP流按消息边界拆包，echo服务能直接把收到的内容原样返回，但业务服务一定要考虑粘包和半包，否则对端收到的消息字节都是乱的。
4. 高频报错排查：我在epoll上踩过的坑
4.1 连接越多越卡，可能不是epoll的锅
新手最容易误判的是：已经把select换成epoll了，连接数一多还是卡。这时候别急着怀疑epoll，先查三件事：每个事件循环里有没有隐藏的阻塞操作；有没有因为漏读导致可读事件反复触发；有没有在业务线程里直接用同一个socket收发。我曾经遇到过一个典型例子：一个连接收到数据后，代码里调用了一次同步磁盘写入，结果写入线程挂着，epoll线程也不得不排队，整个服务都跟着慢。排查这类问题，可以把每个事件处理函数里耗时操作列出来，再配合日志看单个事件的平均处理时长，超过1毫秒就要警惕。
还有一个容易被忽略的问题：EPOLLIN和EPOLLOUT可能同时出现在同一个event掩码里。有些代码用if/elif把这两种情况分开，就可能导致本该写数据的时候没写，本该读数据的时候没读。正确的写法是用多个独立的if判断，每个事件类型单独处理，我上面的代码就是这个风格。
4.2 ET模式下数据读不完导致“静默”
如果你决定用边缘触发，最常见的坑是这个：socket上一次性到了几KB数据，recv只读走一部分，然后你继续等下一次EPOLLIN事件，结果它永远不来了。因为ET只在“无数据→有数据”的边界通知一次，读不完的剩余数据还在缓冲区，但不会再触发通知。解决办法只有一个：ET模式下读到BlockingIOError为止，把缓冲区的数据全部取完；写方向同理，只要EPOLLOUT触发，就尽量把发送缓冲区清空，清空失败也要记住还剩多少，别把fd改成只看EPOLLIN，否则数据一直躺在应用层发送缓冲区里发不出去。
用ET还有一个需要重点检查的地方：销毁一个socket后，它的残留数据是否也从read_bufs和write_bufs里清掉了。如果没清，下一次fd被复用，可能把旧数据发给新连接，这类bug非常隐蔽，又不常出现，是最难查的那一类。我在代码里把清理动作统一放到cleanup函数里，包括unregister、close、pop三个动作，就是为了避免这种残留问题。
4.3 文件描述符复用引发的伪事件与僵尸注册
Linux里fd的编号是会复用的。如果某个连接退出时没有调用epoll.unregister，下次内核给新连接分配了同一个fd，你的事件处理逻辑就可能把这个fd当成旧连接处理，轻则发错数据，重则丢连接。在我的项目里，清理动作必须做到：在收到EPOLLERR/EPOLLHUP/EPOLLRDHUP时立即unregister；在处理完recv返回空数据时立即unregister再close；在主动关闭连接前也要unregister。顺手把读缓冲区、写缓冲区、业务状态全部pop掉，避免内存和状态泄漏。
另一个容易遇到的报错是attempt to register already registered fd或者attempt to unregister an fd not registered。通常不是系统bug，而是代码路径重复执行了register/unregister。比如accept循环里每轮都register同一个conn_fd，或者清理函数在EPOLLIN和EPOLLHUP两个分支里被调了两次。把register操作严格限制在创建连接的那个分支，把unregister放到一个专门的清理函数里，并且用pop而不是get再pop，就能避免大部分误用。
4.4 epoll wait空转与CPU占用过高
还有一个常见现象：没有任何业务流量，CPU占用却居高不下。这时检查ep.poll的timeout是不是传成了0或一个很小的负数。timeout=0表示非阻塞轮询，如果外部while循环里没有sleep，程序就会空转；在极端情况下，如果timeout传成None而fd一直没有事件，线程会一直阻塞，CPU反而很低。正常情况下，没业务流量的服务应该一直阻塞在epoll_wait，CPU占用接近0。如果CPU很高，打开性能分析器看调用栈，十有八九是poll timeout或某个循环里的非阻塞代码在反复执行。
除了CPU，还要留意内存。如果每个连接都分配了独立的读缓冲和写缓冲，而清理函数漏掉了pop，时间长了内存就会悄悄涨上去。这不是epoll本身的问题，是应用层状态管理的锅，但表现形式很像epoll“泄漏了”。遇到内存只增不减，优先检查connections、read_bufs、write_bufs这三个字典的大小。
5. 从epoll到生产级方案：选型与架构思考
5.1 直接用epoll还是用selectors/asyncio封装
Python里其实有更高层的封装，比如selectors模块，它在Linux底层用的也是epoll，把就绪事件以回调函数形式暴露出来；asyncio的事件循环在Linux下同样是基于epoll实现的。那还有必要学裸epoll吗？我的看法是：必须学。因为selectors和asyncio帮你隐藏了大量细节，一旦你的服务出现异常，你依然要回到fd、事件、状态机这一层才能定位问题。而且有些底层需求，比如注册EPOLLRDHUP、精确控制ET模式、批量处理事件，直接操作epoll反而更顺手。
反过来，如果项目节奏紧，需要快速搭建业务服务，那我建议优先用asyncio，它的协议封装和流控制能省很多事，底层性能损失在大多数应用场景可以接受。裸epoll更适合做网关、代理、中间件，以及想掌控每一条连接状态的个人项目。具体怎么选，取决于你是想快速交付业务，还是想把网络层做到极致。
5.2 单线程事件循环与多线程/多进程组合
单线程epoll是事件驱动的基础形态，它最大的优点是简单、没有锁竞争的问题，但它在多核机器上用不满CPU，单核性能再高也算浪费机器。生产级方案通常有两条路：一条是“事件循环+线程池”，把CPU密集或阻塞的业务操作丢给线程池，网络层保持单线程；另一条是“多进程+SO_REUSEPORT”，每个进程一个epoll实例，监听同一个端口，内核负责负载均衡，既用满多核又能隔离故障，很多代理类服务就是这么设计的。
多进程方案需要小心的点是：连接一旦accept进某个进程，后续这个fd就只归它管，跨进程迁移连接很麻烦。如果连接生命周期长而业务量稳定，多进程加SO_REUSEPORT完全够用；如果需要做连接级别的负载均衡、迁移或灰度，可以再考虑在应用层做代理拆包。但不管选哪种，epoll作为底层的I/O核心都没有变化。
5.3 对新手的一段话
最后说点实在的。epoll并不是什么高深秘诀，它就是内核提供的一个基础能力，真正的难度在于你会不会设计好事件状态机、管理好每个连接的生命周期。我见过不少项目死磕ET却忽略缓冲区管理，也有项目用LT模式轻轻松松稳住几万连接。宁可先用LT把逻辑跑对，再往ET和性能优化方向迭代，也比一上来追求极致模式、最后被数据丢失问题折磨要好得多。这个思路放到任何一个高并发组件上都是通用的：先把不变量控制住，再谈性能。
另外，如果你真的在Linux上做高并发服务，记得先把文件描述符上限提上去，再把监听socket设置好SO_REUSEADDR，然后把业务处理和网络收发拆开分层。这三件事做好，用epoll写出一个稳定服务的基本盘就有了。剩下的细节，都是在这个框架里慢慢补。
