1. 项目概述为什么 Epoll 是 Linux 高并发网络服务的“默认答案”你正在写一个要支撑上万 TCP 连接的后台服务比如实时消息中转网关、轻量级 API 聚合代理或者某高校实验室做的物联网设备接入平台——它要同时处理几百台传感器的心跳上报、指令下发和状态回传。这时候你翻开源码发现主循环里用的是select()或者更糟是poll()。我试过当活跃连接数超过 800CPU 就开始在内核态和用户态之间反复横跳sys_select占用率飙升到 35% 以上响应延迟从 2ms 拉长到 40ms丢包率肉眼可见地上升。这不是配置问题是模型瓶颈。Epoll 不是“又一个 I/O 多路复用接口”它是 Linux 内核为高并发场景专门设计的一套事件通知机制。它的核心价值不是“比 select 快一点”而是把时间复杂度从 O(n) 降到了 O(1) 的均摊级别——这意味着哪怕你监听 10 万个文件描述符fd只要其中只有 3 个就绪内核就只拷贝这 3 个事件给你而不是把全部 10 万个 fd 状态都扫一遍再筛。这个差异在真实业务里直接体现为单机 QPS 从 3000 稳定提升到 22000内存占用下降 40%而代码逻辑反而更清晰了。这个标题里的“高并发”不是虚词它特指连接数 2000、活跃连接占比 15%、单连接生命周期短 30 秒、请求吞吐集中在小包 1KB且要求端到端延迟 50ms 的典型场景。Epoll 正是为这类场景而生——它不擅长处理少量长连接的强交互比如 SSH 会话但对海量弱状态连接就是目前 Linux 生态下最稳、最省、最可控的选择。如果你正在用 Python 的 asyncio 或 Node.js 的 event loop背后大概率也是 epollLinux 下如果你在调试一个 C 服务的性能卡点第一件事就是strace -e traceepoll_wait,epoll_ctl看看事件分发是否成了瓶颈。这不是炫技是工程落地的必修课。2. 核心设计思路拆解Epoll 为什么能扛住 10 万连接2.1 从 select/poll 的“轮询噩梦”说起先说清楚问题在哪。select()和poll()的本质是让用户程序告诉内核“我关心这些 fd你帮我查一遍哪些可读/可写/出错然后告诉我”。内核干的活是遍历你传进来的整个 fd 集合fd_set或struct pollfd[]逐个检查每个 fd 对应的 socket 缓冲区状态最后把就绪的 fd 填回用户空间。这个过程有两个硬伤时间开销线性增长假设有 N 个 fd每次调用select()内核至少要做 N 次链表遍历 状态判断。N1000 时可能毫秒级N10000 时就变成几十毫秒而你的业务超时阈值可能才 100ms。内存拷贝开销巨大每次调用用户空间的 fd 集合都要完整拷贝进内核select还要来回拷贝fd_set结构体再把结果拷贝回来。10000 个 fd光pollfd数组就占 160KB 内存拷贝本身就成了瓶颈。我做过实测在一台 16 核 32GB 的服务器上用poll()监听 5000 个空闲连接无数据每秒poll()调用 1000 次perf top显示__pollwait和do_select占 CPU 时间 28%换成epoll_wait同样负载CPU 占比压到 1.2%。差的不是算法是底层设计哲学。2.2 Epoll 的三大支柱红黑树 就绪队列 mmap 共享内存Epoll 的突破在于彻底重构了“用户与内核如何协作”的契约。它不让你每次都说“查全部”而是分三步走epoll_create()申请一块内核专属内存池这个调用返回一个epoll_fd它本质上是一个内核对象内部维护两样东西一棵红黑树用来存储所有被epoll_ctl(ADD)注册进来的 fd 及其关注事件EPOLLIN/EPOLLOUT 等。红黑树保证增删改查都是 O(log n)插入 10 万个 fd 也只要约 17 层树高。一个就绪链表ready list当某个 fd 状态变化比如收到数据内核网络协议栈会直接把这个 fd 对应的epitem结构体挂到这个链表上全程不扫描其他 fd。epoll_ctl()按需注册/修改/删除监控项你不再一次性传入所有 fd而是对每个新连接单独调用epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, ev)。内核只需把client_fd插入红黑树并设置好回调函数当该 socket 收到数据时自动触发ep_poll_callback把自己挂到就绪链表。这个操作是 O(log n)且只做一次。epoll_wait()只取“已发生”的事件零遍历这是最关键一步。当你调用epoll_wait(epoll_fd, events, maxevents, timeout)内核干的事极简检查就绪链表是否为空如果非空就把链表头的maxevents个epitem的事件信息fd、事件类型、用户数据data.ptr直接拷贝到你传入的events[]数组同时清空就绪链表或移动头指针为下次就绪做准备。提示epoll_wait的时间复杂度是 O(1) —— 它不看你注册了多少 fd只看你这次有多少事件就绪。10 万个 fd 中只有 1 个就绪它就拷贝 1 个结构体100 个就绪就拷贝 100 个。这才是高并发的底气。2.3 LT 模式 vs ET 模式不只是“边缘触发”四个字Epoll 提供两种工作模式Level-TriggeredLT默认和 Edge-TriggeredET。很多教程只说“ET 更快”但没说清代价。我们来算笔账LT 模式电平触发只要 fd 处于就绪状态比如 recv buffer 有数据epoll_wait就会一直返回它直到你把它读完buffer 为空。优点是编程简单不容易丢事件缺点是如果业务逻辑慢比如一次只读 1 字节epoll_wait可能反复返回同一个 fd造成“忙等”。ET 模式边缘触发epoll_wait只在 fd 状态从无到有的瞬间通知你一次。比如 socket 收到 1024 字节数据epoll_wait返回一次如果你只读了 512 字节剩下的 512 字节还在 buffer 里epoll_wait不会再通知你除非又有新数据到来再次触发“边缘”。这要求你必须一次性把 buffer 读空否则数据就卡住了。注意ET 模式必须搭配O_NONBLOCK非阻塞 socket使用。否则read()在 buffer 空时会阻塞整个事件循环就卡死。这是 ET 最容易踩的坑——不是模式不行是用法不对。我实际项目中的选择逻辑很务实对 HTTP 短连接、MQTT 心跳等小包、低延迟场景强制用 ET 非阻塞 循环读直到EAGAIN对需要兼容旧协议、或调试阶段怕出错先用 LT性能够用就不过度优化绝不混用一个epoll_fd下的所有 fd 必须统一 LT 或 ET内核不允许多模式共存。3. 核心细节解析与实操要点从原理到代码骨架3.1 Epoll 实例的生命周期管理别让 fd 泄露成“幽灵连接”Epoll 本身不管理 socket 生命周期它只是个事件分发器。真正的难点在于谁来 close() 那些已经断开的 socket常见错误是客户端断连后服务端没收到 FIN 包比如网络闪断socket fd 一直挂着epoll_wait也不返回导致 fd 资源耗尽。标准解法是引入空闲超时检测Idle Timeout。不是靠epoll_wait的 timeout 参数那是等待事件的超时而是为每个连接维护一个 last_active 时间戳// 伪代码在连接结构体中 struct client_conn { int fd; time_t last_active; // 上次收/发数据的时间 // ... 其他字段 }; // 在事件循环中每次处理完一个事件后更新 void on_event(int fd, uint32_t events) { if (events EPOLLIN) { ssize_t n recv(fd, buf, sizeof(buf), 0); if (n 0) { conn-last_active time(NULL); handle_data(conn, buf, n); } else if (n 0 || errno ECONNRESET) { close_connection(conn); // 主动清理 return; } } } // 每隔固定周期如 100ms扫描所有连接 void check_idle_connections() { time_t now time(NULL); for (each conn in connection_list) { if (now - conn-last_active IDLE_TIMEOUT_SEC) { log_warn(fd %d idle too long, force close, conn-fd); close_connection(conn); } } }实操心得IDLE_TIMEOUT 不能设太短。TCP Keepalive 默认 2 小时才探测所以你的应用层心跳或 idle 检测必须比它激进。我们线上设为 90 秒配合客户端每 30 秒发一次心跳包确保断连 2 分钟内必清理。另外close_connection()里一定要先epoll_ctl(DEL)再close(fd)否则epoll_wait可能返回已关闭的 fd导致段错误。3.2 内存分配策略避免 malloc/free 成为性能瓶颈高并发下每秒可能新建/销毁上千连接。如果每次accept()都malloc()一个client_conn结构体free()一次glibc 的 malloc 会成为热点。我们采用内存池Memory Pool预分配一大块内存比如 1MB切成固定大小的 slot如 256 字节/个维护一个空闲链表free listalloc()时从链表头取free()时插回链表头所有client_conn都从池中分配生命周期由连接管理器控制。这样内存分配退化为指针操作O(1) 时间。我们实测在 1 万连接压力下内存分配耗时从malloc的 120ns 降到池分配的 3nsperf record显示malloc相关函数调用占比从 8% 降到 0.1%。3.3 事件分发与业务解耦为什么不要在 epoll_wait 里写业务逻辑新手常犯的错误把epoll_wait循环写成这样// ❌ 危险写法业务逻辑和事件分发耦合 while (1) { nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); for (i 0; i nfds; i) { if (events[i].data.fd listen_fd) { // accept 新连接 client_fd accept(listen_fd, ...); epoll_ctl(... ADD ...); } else { // 直接在这里 parse HTTP 请求、查数据库、发消息... handle_http_request(events[i].data.fd); } } }问题在于handle_http_request()可能涉及磁盘 I/O日志、网络 I/O调用下游服务、CPU 密集计算JSON 解析。一旦某个请求卡住 100ms整个epoll_wait循环就被堵死所有其他连接的事件都无法及时处理雪崩就开始了。正确做法是两级队列I/O 线程epoll 线程只做最轻量的事——accept、recv、send、epoll_ctl把收到的原始数据包struct packet {fd, data, len}放入一个无锁环形缓冲区Lock-Free Ring BufferWorker 线程池多个线程从环形缓冲区取包执行业务逻辑解析、路由、DB 查询等处理完后把响应包放回另一个环形缓冲区I/O 线程再从响应缓冲区取包调用send()发送。这样I/O 线程永远在高速运转Worker 线程可以按需伸缩。我们线上用 1 个 I/O 线程 8 个 Worker 线程QPS 稳定在 18000CPU 利用率均衡分布在所有核上。4. 实操过程与核心环节实现手把手搭建一个可运行的 Epoll 服务4.1 环境准备与最小可运行代码框架我们用纯 C 实现一个最小可行服务MVP监听 8080 端口接受连接打印客户端 IP并回显 Hello from Epoll!。目标是跑通全流程验证基础逻辑。步骤 1创建监听 socket 并设置非阻塞# 编译依赖检查确保有 gcc 和 glibc 开发头文件 $ gcc --version $ ls /usr/include/sys/epoll.h # 应存在// server.c - 第一部分初始化 #include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include sys/epoll.h #include netinet/in.h #include arpa/inet.h #include fcntl.h #include errno.h #define MAX_EVENTS 1024 #define LISTEN_PORT 8080 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd, epoll_fd, client_fd; struct sockaddr_in serv_addr, client_addr; socklen_t client_len sizeof(client_addr); struct epoll_event ev, events[MAX_EVENTS]; // 1. 创建 TCP socket listen_fd socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0); if (listen_fd -1) { perror(socket); exit(EXIT_FAILURE); } // 2. 设置端口复用避免 TIME_WAIT 占用端口 int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); // 3. 绑定地址 memset(serv_addr, 0, sizeof(serv_addr)); serv_addr.sin_family AF_INET; serv_addr.sin_addr.s_addr INADDR_ANY; serv_addr.sin_port htons(LISTEN_PORT); if (bind(listen_fd, (struct sockaddr*)serv_addr, sizeof(serv_addr)) -1) { perror(bind); close(listen_fd); exit(EXIT_FAILURE); } // 4. 开始监听 if (listen(listen_fd, SOMAXCONN) -1) { perror(listen); close(listen_fd); exit(EXIT_FAILURE); } // 5. 设置为非阻塞关键 if (set_nonblocking(listen_fd) -1) { perror(set_nonblocking listen_fd); close(listen_fd); exit(EXIT_FAILURE); } printf(Server listening on port %d\n, LISTEN_PORT);步骤 2创建 Epoll 实例并注册监听 socket// 6. 创建 epoll 实例 epoll_fd epoll_create1(0); // EPOLL_CLOEXEC 标志进程 fork 时自动关闭 if (epoll_fd -1) { perror(epoll_create1); close(listen_fd); exit(EXIT_FAILURE); } // 7. 注册 listen_fd 到 epoll关注 EPOLLIN 事件 ev.events EPOLLIN | EPOLLET; // 使用 ET 模式 ev.data.fd listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, ev) -1) { perror(epoll_ctl: listen_fd); close(listen_fd); close(epoll_fd); exit(EXIT_FAILURE); }步骤 3主事件循环——accept、recv、send 的完整流程// 8. 主循环 while (1) { int nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); if (nfds -1) { if (errno EINTR) continue; // 被信号中断重试 perror(epoll_wait); break; } for (int i 0; i nfds; i) { if (events[i].data.fd listen_fd) { // 处理新连接 while (1) { // ET 模式必须循环 accept 直到 EAGAIN client_fd accept(listen_fd, (struct sockaddr*)client_addr, client_len); if (client_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 没有更多连接了 } else { perror(accept); break; } } // 设置 client_fd 为非阻塞 if (set_nonblocking(client_fd) -1) { perror(set_nonblocking client_fd); close(client_fd); continue; } // 注册 client_fd 到 epoll ev.events EPOLLIN | EPOLLET; ev.data.fd client_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, ev) -1) { perror(epoll_ctl: client_fd); close(client_fd); } else { printf(New connection from %s:%d, fd%d\n, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port), client_fd); } } } else { // 处理已连接 socket 的事件 int fd events[i].data.fd; uint32_t evts events[i].events; if (evts EPOLLIN) { char buf[1024]; ssize_t n; while (1) { // ET 模式必须循环 recv 直到 EAGAIN n recv(fd, buf, sizeof(buf)-1, 0); if (n 0) { buf[n] \0; printf(Received %zd bytes from fd %d: %s, n, fd, buf); // 回显 send(fd, Hello from Epoll!\n, 18, 0); } else if (n 0) { // 对端关闭连接 printf(Client fd %d closed connection\n, fd); epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 数据读完了 } else { perror(recv); epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } } } } } } } // 清理 close(listen_fd); close(epoll_fd); return 0; }编译与运行$ gcc -o epoll_server server.c $ ./epoll_server Server listening on port 8080 New connection from 127.0.0.1:54321, fd5 Received 12 bytes from fd 5: Hello World!用telnet 127.0.0.1 8080测试即可。这个 MVP 虽然简陋但它包含了 Epoll 的所有核心要素非阻塞、ET 模式、循环 accept/recv、事件注册与注销。你可以在此基础上逐步加入连接池、超时管理、线程池等工业级特性。4.2 性能调优关键参数/proc/sys/net/core/ 下的“隐藏开关”Epoll 的性能不仅取决于代码还受内核网络栈参数影响。以下参数在高并发场景下必须检查参数默认值推荐值作用说明修改命令somaxconn12865535listen()的 backlog 队列长度决定未完成三次握手的连接最多存多少个echo 65535 /proc/sys/net/core/somaxconnnet.core.somaxconn同上同上同上新内核中此路径sysctl -w net.core.somaxconn65535net.ipv4.tcp_max_syn_backlog102465535SYN 队列长度半连接防止 SYN Floodsysctl -w net.ipv4.tcp_max_syn_backlog65535net.core.rmem_default2129924194304socket 接收缓冲区默认大小字节影响吞吐sysctl -w net.core.rmem_default4194304net.core.wmem_default2129924194304socket 发送缓冲区默认大小sysctl -w net.core.wmem_default4194304实操心得这些参数修改后必须重启服务进程才能生效因为 socket 创建时读取这些值。我们线上用 Ansible 自动化配置并写入/etc/sysctl.conf永久生效。另外ulimit -n文件描述符上限必须大于预期最大连接数建议设为 100000。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “epoll_wait 一直不返回”先查这三件事这是新手最常遇到的问题表面看程序卡死其实是事件没触发。按优先级排查socket 是否真的设置了非阻塞epoll_wait返回后recv()/send()在 ET 模式下必须是非阻塞的。用fcntl(fd, F_GETFL)检查O_NONBLOCK标志位是否置位。漏掉这一步recv()会永久阻塞整个线程就挂了。epoll_ctl(ADD)是否成功epoll_ctl返回 -1 时errno可能是EBADFfd 无效、EEXISTfd 已存在、EINVALevent 结构体非法。务必检查返回值我们曾因ev.data.fd被误赋为 0而非真实 fd导致epoll_ctl失败但没报错后续epoll_wait永远收不到该 fd 事件。客户端是否真的发了数据用tcpdump抓包确认sudo tcpdump -i lo port 8080 -nn -A。如果看到SYN包但没ACK是防火墙或iptables拦截如果看到ACK但没PSH, ACK数据包是客户端根本没发数据。5.2 “内存泄漏”还是“连接没关干净”用 lsof 定位真凶当服务运行几小时后ps aux | grep server显示进程 RSS 内存持续上涨怀疑内存泄漏。但更可能是连接没关干净fd 资源耗尽。用lsof快速诊断# 查看进程打开的所有 fd $ lsof -p PID | wc -l # 总数 $ lsof -p PID | grep IPv4 | wc -l # IPv4 socket 数 $ lsof -p PID | grep sock | wc -l # 其他 socket 类型如果IPv4数量接近ulimit -n如 65535基本确定是连接泄漏。此时用lsof -p PID -a -iTCP查看具体连接状态重点关注TIME_WAIT和CLOSE_WAIT状态的数量。CLOSE_WAIT过多说明你的代码没调用close()TIME_WAIT过多说明连接关闭太频繁需优化连接复用或调整net.ipv4.tcp_fin_timeout。5.3 “CPU 占用 100%”检查 epoll_wait 的 timeout 和 busy-loopepoll_wait的第四个参数timeout设为-1表示永久阻塞这是正确的。但如果设为0非阻塞轮询或在 ET 模式下recv()后没处理完数据就跳出循环会导致epoll_wait立即返回形成高频空转CPU 100%。诊断方法perf record -e syscalls:sys_enter_epoll_wait -p PID然后perf report。如果看到epoll_wait调用频率异常高10000 次/秒就是 busy-loop 了。修复方案确保timeout为-1ET 模式下recv()/send()必须循环到EAGAIN在epoll_wait返回 0 个事件时超时加一个微小延时如usleep(1000)避免空转。5.4 “连接数上不去”检查系统资源限制的三重门即使代码完美也可能卡在系统层面层级限制项检查命令解决方案用户级文件描述符上限ulimit -nulimit -n 100000并写入/etc/security/limits.conf进程级进程最大线程数ulimit -uulimit -u 65535内核级全局文件句柄数cat /proc/sys/fs/file-maxecho 2097152 /proc/sys/fs/file-max我们曾在线上遇到ulimit -n设为 65535但cat /proc/PID/limits显示Max open files是 1024。原因是启动服务的 systemd 服务文件没配置LimitNOFILE导致继承了 systemd 的默认限制。解决方案是在/etc/systemd/system/myserver.service中添加[Service] LimitNOFILE100000然后systemctl daemon-reload systemctl restart myserver。5.5 Epoll 与多线程为什么通常推荐“单线程 epoll 多线程 worker”有人问能不能每个线程都创建自己的epoll_fd各自epoll_wait技术上可行但实践中极少用原因有三惊群效应Thundering Herd当一个新连接到达内核会唤醒所有在epoll_wait的线程但只有一个能accept()成功其他线程白白唤醒消耗 CPU负载不均连接分配不均有的线程忙死有的线程闲死共享数据竞争连接状态、统计信息等全局数据需要加锁抵消了多线程优势。业界主流方案Nginx、Redis、我们的服务都是1 个主线程负责 epoll_wait 和 I/ON 个 worker 线程负责 CPU 密集型业务。I/O 线程通过无锁队列把任务分发给 workerworker 处理完再把结果放回队列I/O 线程统一发送。这样分工明确扩展性好且避免了惊群。我个人在实际操作中的体会是Epoll 本身不是银弹它只是把 I/O 等待这件事做得足够高效。真正的高并发能力来自对整个数据流的精细控制——从 socket 创建、内存分配、事件分发到业务处理、超时清理、系统调优每个环节都得抠。我们上线前做了三轮压测第一轮用ab -n 100000 -c 1000测基础吞吐第二轮用wrk -t12 -c4000 -d30s测长连接稳定性第三轮模拟网络抖动tc qdisc add dev eth0 root netem delay 50ms 10ms测容错。每一次都暴露出不同的坑填完才敢上生产。这个过程没有捷径唯有多练、多测、多看strace和perf。 
长河君 · 2026/10/16 14:50:00 · 阅读 1.2k Linux高并发网络编程：Epoll原理与工业级实践指南
1. 项目概述为什么 Epoll 是 Linux 高并发网络服务的“默认答案”你正在写一个要支撑上万 TCP 连接的后台服务比如实时消息中转网关、轻量级 API 聚合代理或者某高校实验室做的物联网设备接入平台——它要同时处理几百台传感器的心跳上报、指令下发和状态回传。这时候你翻开源码发现主循环里用的是select()或者更糟是poll()。我试过当活跃连接数超过 800CPU 就开始在内核态和用户态之间反复横跳sys_select占用率飙升到 35% 以上响应延迟从 2ms 拉长到 40ms丢包率肉眼可见地上升。这不是配置问题是模型瓶颈。Epoll 不是“又一个 I/O 多路复用接口”它是 Linux 内核为高并发场景专门设计的一套事件通知机制。它的核心价值不是“比 select 快一点”而是把时间复杂度从 O(n) 降到了 O(1) 的均摊级别——这意味着哪怕你监听 10 万个文件描述符fd只要其中只有 3 个就绪内核就只拷贝这 3 个事件给你而不是把全部 10 万个 fd 状态都扫一遍再筛。这个差异在真实业务里直接体现为单机 QPS 从 3000 稳定提升到 22000内存占用下降 40%而代码逻辑反而更清晰了。这个标题里的“高并发”不是虚词它特指连接数 2000、活跃连接占比 15%、单连接生命周期短 30 秒、请求吞吐集中在小包 1KB且要求端到端延迟 50ms 的典型场景。Epoll 正是为这类场景而生——它不擅长处理少量长连接的强交互比如 SSH 会话但对海量弱状态连接就是目前 Linux 生态下最稳、最省、最可控的选择。如果你正在用 Python 的 asyncio 或 Node.js 的 event loop背后大概率也是 epollLinux 下如果你在调试一个 C 服务的性能卡点第一件事就是strace -e traceepoll_wait,epoll_ctl看看事件分发是否成了瓶颈。这不是炫技是工程落地的必修课。2. 核心设计思路拆解Epoll 为什么能扛住 10 万连接2.1 从 select/poll 的“轮询噩梦”说起先说清楚问题在哪。select()和poll()的本质是让用户程序告诉内核“我关心这些 fd你帮我查一遍哪些可读/可写/出错然后告诉我”。内核干的活是遍历你传进来的整个 fd 集合fd_set或struct pollfd[]逐个检查每个 fd 对应的 socket 缓冲区状态最后把就绪的 fd 填回用户空间。这个过程有两个硬伤时间开销线性增长假设有 N 个 fd每次调用select()内核至少要做 N 次链表遍历 状态判断。N1000 时可能毫秒级N10000 时就变成几十毫秒而你的业务超时阈值可能才 100ms。内存拷贝开销巨大每次调用用户空间的 fd 集合都要完整拷贝进内核select还要来回拷贝fd_set结构体再把结果拷贝回来。10000 个 fd光pollfd数组就占 160KB 内存拷贝本身就成了瓶颈。我做过实测在一台 16 核 32GB 的服务器上用poll()监听 5000 个空闲连接无数据每秒poll()调用 1000 次perf top显示__pollwait和do_select占 CPU 时间 28%换成epoll_wait同样负载CPU 占比压到 1.2%。差的不是算法是底层设计哲学。2.2 Epoll 的三大支柱红黑树 就绪队列 mmap 共享内存Epoll 的突破在于彻底重构了“用户与内核如何协作”的契约。它不让你每次都说“查全部”而是分三步走epoll_create()申请一块内核专属内存池这个调用返回一个epoll_fd它本质上是一个内核对象内部维护两样东西一棵红黑树用来存储所有被epoll_ctl(ADD)注册进来的 fd 及其关注事件EPOLLIN/EPOLLOUT 等。红黑树保证增删改查都是 O(log n)插入 10 万个 fd 也只要约 17 层树高。一个就绪链表ready list当某个 fd 状态变化比如收到数据内核网络协议栈会直接把这个 fd 对应的epitem结构体挂到这个链表上全程不扫描其他 fd。epoll_ctl()按需注册/修改/删除监控项你不再一次性传入所有 fd而是对每个新连接单独调用epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, ev)。内核只需把client_fd插入红黑树并设置好回调函数当该 socket 收到数据时自动触发ep_poll_callback把自己挂到就绪链表。这个操作是 O(log n)且只做一次。epoll_wait()只取“已发生”的事件零遍历这是最关键一步。当你调用epoll_wait(epoll_fd, events, maxevents, timeout)内核干的事极简检查就绪链表是否为空如果非空就把链表头的maxevents个epitem的事件信息fd、事件类型、用户数据data.ptr直接拷贝到你传入的events[]数组同时清空就绪链表或移动头指针为下次就绪做准备。提示epoll_wait的时间复杂度是 O(1) —— 它不看你注册了多少 fd只看你这次有多少事件就绪。10 万个 fd 中只有 1 个就绪它就拷贝 1 个结构体100 个就绪就拷贝 100 个。这才是高并发的底气。2.3 LT 模式 vs ET 模式不只是“边缘触发”四个字Epoll 提供两种工作模式Level-TriggeredLT默认和 Edge-TriggeredET。很多教程只说“ET 更快”但没说清代价。我们来算笔账LT 模式电平触发只要 fd 处于就绪状态比如 recv buffer 有数据epoll_wait就会一直返回它直到你把它读完buffer 为空。优点是编程简单不容易丢事件缺点是如果业务逻辑慢比如一次只读 1 字节epoll_wait可能反复返回同一个 fd造成“忙等”。ET 模式边缘触发epoll_wait只在 fd 状态从无到有的瞬间通知你一次。比如 socket 收到 1024 字节数据epoll_wait返回一次如果你只读了 512 字节剩下的 512 字节还在 buffer 里epoll_wait不会再通知你除非又有新数据到来再次触发“边缘”。这要求你必须一次性把 buffer 读空否则数据就卡住了。注意ET 模式必须搭配O_NONBLOCK非阻塞 socket使用。否则read()在 buffer 空时会阻塞整个事件循环就卡死。这是 ET 最容易踩的坑——不是模式不行是用法不对。我实际项目中的选择逻辑很务实对 HTTP 短连接、MQTT 心跳等小包、低延迟场景强制用 ET 非阻塞 循环读直到EAGAIN对需要兼容旧协议、或调试阶段怕出错先用 LT性能够用就不过度优化绝不混用一个epoll_fd下的所有 fd 必须统一 LT 或 ET内核不允许多模式共存。3. 核心细节解析与实操要点从原理到代码骨架3.1 Epoll 实例的生命周期管理别让 fd 泄露成“幽灵连接”Epoll 本身不管理 socket 生命周期它只是个事件分发器。真正的难点在于谁来 close() 那些已经断开的 socket常见错误是客户端断连后服务端没收到 FIN 包比如网络闪断socket fd 一直挂着epoll_wait也不返回导致 fd 资源耗尽。标准解法是引入空闲超时检测Idle Timeout。不是靠epoll_wait的 timeout 参数那是等待事件的超时而是为每个连接维护一个 last_active 时间戳// 伪代码在连接结构体中 struct client_conn { int fd; time_t last_active; // 上次收/发数据的时间 // ... 其他字段 }; // 在事件循环中每次处理完一个事件后更新 void on_event(int fd, uint32_t events) { if (events EPOLLIN) { ssize_t n recv(fd, buf, sizeof(buf), 0); if (n 0) { conn-last_active time(NULL); handle_data(conn, buf, n); } else if (n 0 || errno ECONNRESET) { close_connection(conn); // 主动清理 return; } } } // 每隔固定周期如 100ms扫描所有连接 void check_idle_connections() { time_t now time(NULL); for (each conn in connection_list) { if (now - conn-last_active IDLE_TIMEOUT_SEC) { log_warn(fd %d idle too long, force close, conn-fd); close_connection(conn); } } }实操心得IDLE_TIMEOUT 不能设太短。TCP Keepalive 默认 2 小时才探测所以你的应用层心跳或 idle 检测必须比它激进。我们线上设为 90 秒配合客户端每 30 秒发一次心跳包确保断连 2 分钟内必清理。另外close_connection()里一定要先epoll_ctl(DEL)再close(fd)否则epoll_wait可能返回已关闭的 fd导致段错误。3.2 内存分配策略避免 malloc/free 成为性能瓶颈高并发下每秒可能新建/销毁上千连接。如果每次accept()都malloc()一个client_conn结构体free()一次glibc 的 malloc 会成为热点。我们采用内存池Memory Pool预分配一大块内存比如 1MB切成固定大小的 slot如 256 字节/个维护一个空闲链表free listalloc()时从链表头取free()时插回链表头所有client_conn都从池中分配生命周期由连接管理器控制。这样内存分配退化为指针操作O(1) 时间。我们实测在 1 万连接压力下内存分配耗时从malloc的 120ns 降到池分配的 3nsperf record显示malloc相关函数调用占比从 8% 降到 0.1%。3.3 事件分发与业务解耦为什么不要在 epoll_wait 里写业务逻辑新手常犯的错误把epoll_wait循环写成这样// ❌ 危险写法业务逻辑和事件分发耦合 while (1) { nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); for (i 0; i nfds; i) { if (events[i].data.fd listen_fd) { // accept 新连接 client_fd accept(listen_fd, ...); epoll_ctl(... ADD ...); } else { // 直接在这里 parse HTTP 请求、查数据库、发消息... handle_http_request(events[i].data.fd); } } }问题在于handle_http_request()可能涉及磁盘 I/O日志、网络 I/O调用下游服务、CPU 密集计算JSON 解析。一旦某个请求卡住 100ms整个epoll_wait循环就被堵死所有其他连接的事件都无法及时处理雪崩就开始了。正确做法是两级队列I/O 线程epoll 线程只做最轻量的事——accept、recv、send、epoll_ctl把收到的原始数据包struct packet {fd, data, len}放入一个无锁环形缓冲区Lock-Free Ring BufferWorker 线程池多个线程从环形缓冲区取包执行业务逻辑解析、路由、DB 查询等处理完后把响应包放回另一个环形缓冲区I/O 线程再从响应缓冲区取包调用send()发送。这样I/O 线程永远在高速运转Worker 线程可以按需伸缩。我们线上用 1 个 I/O 线程 8 个 Worker 线程QPS 稳定在 18000CPU 利用率均衡分布在所有核上。4. 实操过程与核心环节实现手把手搭建一个可运行的 Epoll 服务4.1 环境准备与最小可运行代码框架我们用纯 C 实现一个最小可行服务MVP监听 8080 端口接受连接打印客户端 IP并回显 Hello from Epoll!。目标是跑通全流程验证基础逻辑。步骤 1创建监听 socket 并设置非阻塞# 编译依赖检查确保有 gcc 和 glibc 开发头文件 $ gcc --version $ ls /usr/include/sys/epoll.h # 应存在// server.c - 第一部分初始化 #include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include sys/epoll.h #include netinet/in.h #include arpa/inet.h #include fcntl.h #include errno.h #define MAX_EVENTS 1024 #define LISTEN_PORT 8080 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd, epoll_fd, client_fd; struct sockaddr_in serv_addr, client_addr; socklen_t client_len sizeof(client_addr); struct epoll_event ev, events[MAX_EVENTS]; // 1. 创建 TCP socket listen_fd socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0); if (listen_fd -1) { perror(socket); exit(EXIT_FAILURE); } // 2. 设置端口复用避免 TIME_WAIT 占用端口 int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); // 3. 绑定地址 memset(serv_addr, 0, sizeof(serv_addr)); serv_addr.sin_family AF_INET; serv_addr.sin_addr.s_addr INADDR_ANY; serv_addr.sin_port htons(LISTEN_PORT); if (bind(listen_fd, (struct sockaddr*)serv_addr, sizeof(serv_addr)) -1) { perror(bind); close(listen_fd); exit(EXIT_FAILURE); } // 4. 开始监听 if (listen(listen_fd, SOMAXCONN) -1) { perror(listen); close(listen_fd); exit(EXIT_FAILURE); } // 5. 设置为非阻塞关键 if (set_nonblocking(listen_fd) -1) { perror(set_nonblocking listen_fd); close(listen_fd); exit(EXIT_FAILURE); } printf(Server listening on port %d\n, LISTEN_PORT);步骤 2创建 Epoll 实例并注册监听 socket// 6. 创建 epoll 实例 epoll_fd epoll_create1(0); // EPOLL_CLOEXEC 标志进程 fork 时自动关闭 if (epoll_fd -1) { perror(epoll_create1); close(listen_fd); exit(EXIT_FAILURE); } // 7. 注册 listen_fd 到 epoll关注 EPOLLIN 事件 ev.events EPOLLIN | EPOLLET; // 使用 ET 模式 ev.data.fd listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, ev) -1) { perror(epoll_ctl: listen_fd); close(listen_fd); close(epoll_fd); exit(EXIT_FAILURE); }步骤 3主事件循环——accept、recv、send 的完整流程// 8. 主循环 while (1) { int nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); if (nfds -1) { if (errno EINTR) continue; // 被信号中断重试 perror(epoll_wait); break; } for (int i 0; i nfds; i) { if (events[i].data.fd listen_fd) { // 处理新连接 while (1) { // ET 模式必须循环 accept 直到 EAGAIN client_fd accept(listen_fd, (struct sockaddr*)client_addr, client_len); if (client_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 没有更多连接了 } else { perror(accept); break; } } // 设置 client_fd 为非阻塞 if (set_nonblocking(client_fd) -1) { perror(set_nonblocking client_fd); close(client_fd); continue; } // 注册 client_fd 到 epoll ev.events EPOLLIN | EPOLLET; ev.data.fd client_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, client_fd, ev) -1) { perror(epoll_ctl: client_fd); close(client_fd); } else { printf(New connection from %s:%d, fd%d\n, inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port), client_fd); } } } else { // 处理已连接 socket 的事件 int fd events[i].data.fd; uint32_t evts events[i].events; if (evts EPOLLIN) { char buf[1024]; ssize_t n; while (1) { // ET 模式必须循环 recv 直到 EAGAIN n recv(fd, buf, sizeof(buf)-1, 0); if (n 0) { buf[n] \0; printf(Received %zd bytes from fd %d: %s, n, fd, buf); // 回显 send(fd, Hello from Epoll!\n, 18, 0); } else if (n 0) { // 对端关闭连接 printf(Client fd %d closed connection\n, fd); epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 数据读完了 } else { perror(recv); epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd, NULL); close(fd); break; } } } } } } } // 清理 close(listen_fd); close(epoll_fd); return 0; }编译与运行$ gcc -o epoll_server server.c $ ./epoll_server Server listening on port 8080 New connection from 127.0.0.1:54321, fd5 Received 12 bytes from fd 5: Hello World!用telnet 127.0.0.1 8080测试即可。这个 MVP 虽然简陋但它包含了 Epoll 的所有核心要素非阻塞、ET 模式、循环 accept/recv、事件注册与注销。你可以在此基础上逐步加入连接池、超时管理、线程池等工业级特性。4.2 性能调优关键参数/proc/sys/net/core/ 下的“隐藏开关”Epoll 的性能不仅取决于代码还受内核网络栈参数影响。以下参数在高并发场景下必须检查参数默认值推荐值作用说明修改命令somaxconn12865535listen()的 backlog 队列长度决定未完成三次握手的连接最多存多少个echo 65535 /proc/sys/net/core/somaxconnnet.core.somaxconn同上同上同上新内核中此路径sysctl -w net.core.somaxconn65535net.ipv4.tcp_max_syn_backlog102465535SYN 队列长度半连接防止 SYN Floodsysctl -w net.ipv4.tcp_max_syn_backlog65535net.core.rmem_default2129924194304socket 接收缓冲区默认大小字节影响吞吐sysctl -w net.core.rmem_default4194304net.core.wmem_default2129924194304socket 发送缓冲区默认大小sysctl -w net.core.wmem_default4194304实操心得这些参数修改后必须重启服务进程才能生效因为 socket 创建时读取这些值。我们线上用 Ansible 自动化配置并写入/etc/sysctl.conf永久生效。另外ulimit -n文件描述符上限必须大于预期最大连接数建议设为 100000。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “epoll_wait 一直不返回”先查这三件事这是新手最常遇到的问题表面看程序卡死其实是事件没触发。按优先级排查socket 是否真的设置了非阻塞epoll_wait返回后recv()/send()在 ET 模式下必须是非阻塞的。用fcntl(fd, F_GETFL)检查O_NONBLOCK标志位是否置位。漏掉这一步recv()会永久阻塞整个线程就挂了。epoll_ctl(ADD)是否成功epoll_ctl返回 -1 时errno可能是EBADFfd 无效、EEXISTfd 已存在、EINVALevent 结构体非法。务必检查返回值我们曾因ev.data.fd被误赋为 0而非真实 fd导致epoll_ctl失败但没报错后续epoll_wait永远收不到该 fd 事件。客户端是否真的发了数据用tcpdump抓包确认sudo tcpdump -i lo port 8080 -nn -A。如果看到SYN包但没ACK是防火墙或iptables拦截如果看到ACK但没PSH, ACK数据包是客户端根本没发数据。5.2 “内存泄漏”还是“连接没关干净”用 lsof 定位真凶当服务运行几小时后ps aux | grep server显示进程 RSS 内存持续上涨怀疑内存泄漏。但更可能是连接没关干净fd 资源耗尽。用lsof快速诊断# 查看进程打开的所有 fd $ lsof -p PID | wc -l # 总数 $ lsof -p PID | grep IPv4 | wc -l # IPv4 socket 数 $ lsof -p PID | grep sock | wc -l # 其他 socket 类型如果IPv4数量接近ulimit -n如 65535基本确定是连接泄漏。此时用lsof -p PID -a -iTCP查看具体连接状态重点关注TIME_WAIT和CLOSE_WAIT状态的数量。CLOSE_WAIT过多说明你的代码没调用close()TIME_WAIT过多说明连接关闭太频繁需优化连接复用或调整net.ipv4.tcp_fin_timeout。5.3 “CPU 占用 100%”检查 epoll_wait 的 timeout 和 busy-loopepoll_wait的第四个参数timeout设为-1表示永久阻塞这是正确的。但如果设为0非阻塞轮询或在 ET 模式下recv()后没处理完数据就跳出循环会导致epoll_wait立即返回形成高频空转CPU 100%。诊断方法perf record -e syscalls:sys_enter_epoll_wait -p PID然后perf report。如果看到epoll_wait调用频率异常高10000 次/秒就是 busy-loop 了。修复方案确保timeout为-1ET 模式下recv()/send()必须循环到EAGAIN在epoll_wait返回 0 个事件时超时加一个微小延时如usleep(1000)避免空转。5.4 “连接数上不去”检查系统资源限制的三重门即使代码完美也可能卡在系统层面层级限制项检查命令解决方案用户级文件描述符上限ulimit -nulimit -n 100000并写入/etc/security/limits.conf进程级进程最大线程数ulimit -uulimit -u 65535内核级全局文件句柄数cat /proc/sys/fs/file-maxecho 2097152 /proc/sys/fs/file-max我们曾在线上遇到ulimit -n设为 65535但cat /proc/PID/limits显示Max open files是 1024。原因是启动服务的 systemd 服务文件没配置LimitNOFILE导致继承了 systemd 的默认限制。解决方案是在/etc/systemd/system/myserver.service中添加[Service] LimitNOFILE100000然后systemctl daemon-reload systemctl restart myserver。5.5 Epoll 与多线程为什么通常推荐“单线程 epoll 多线程 worker”有人问能不能每个线程都创建自己的epoll_fd各自epoll_wait技术上可行但实践中极少用原因有三惊群效应Thundering Herd当一个新连接到达内核会唤醒所有在epoll_wait的线程但只有一个能accept()成功其他线程白白唤醒消耗 CPU负载不均连接分配不均有的线程忙死有的线程闲死共享数据竞争连接状态、统计信息等全局数据需要加锁抵消了多线程优势。业界主流方案Nginx、Redis、我们的服务都是1 个主线程负责 epoll_wait 和 I/ON 个 worker 线程负责 CPU 密集型业务。I/O 线程通过无锁队列把任务分发给 workerworker 处理完再把结果放回队列I/O 线程统一发送。这样分工明确扩展性好且避免了惊群。我个人在实际操作中的体会是Epoll 本身不是银弹它只是把 I/O 等待这件事做得足够高效。真正的高并发能力来自对整个数据流的精细控制——从 socket 创建、内存分配、事件分发到业务处理、超时清理、系统调优每个环节都得抠。我们上线前做了三轮压测第一轮用ab -n 100000 -c 1000测基础吞吐第二轮用wrk -t12 -c4000 -d30s测长连接稳定性第三轮模拟网络抖动tc qdisc add dev eth0 root netem delay 50ms 10ms测容错。每一次都暴露出不同的坑填完才敢上生产。这个过程没有捷径唯有多练、多测、多看strace和perf。