从select到epoll：Linux网络编程IO多路复用实战与ET边缘触发解析

先交代一句：这篇是“续”，上一篇我把 select/poll/epoll 的 API 和基本用法过了一遍，这次直接往前推一步，聊实战中真正要命的东西——性能差异背后的原理、边缘触发的正确打开方式、fd 生命周期管理，以及我在几个真实项目里踩过的坑。文章里所有代码都基于 Linux 平台，写的都是可直接编译运行的示例，场景上以 TCP 服务端为主，因为大部分网络服务的核心逻辑都在服务端。

1. select：基础但坑不少

先别急着嘲笑 select 老，它到现在还在大量代码库里服役，不是没有原因的。它简单，跨平台性极好，Windows、Linux、macOS 全都有，而且只要你管理的连接数不超过几十个，性能完全够用。我见过某企业内部的运维平台，一个管理服务用 select 扛了两百多个客户端，跑了几年没出过问题。

1.1 核心机制与 fd_set 操作细节

select 的工作机制可以用一句话讲清楚：它让你把关心的文件描述符（简称 fd）放进一个集合，然后交给内核去轮询这些 fd 是否有事件就绪，有就通知你。用户态和内核态之间通过三个 fd_set 结构传递数据：读集合、写集合、异常集合。

这里有一个很多初学者会忽略的关键点：fd_set 是值传递的。你调用 select(fdmax+1, &readfds, NULL, NULL, &timeout) 之后，内核会根据传入的集合做修改，返回时 readfds 中保留的是【有事件就绪】的 fd，未就绪的会被清掉。所以每次调用 select 之前，你必须重新把要监视的 fd 加回集合里，不能复用上一次返回的集合。

c复制#include <sys/select.h>
#include <sys/time.h>
#include <unistd.h>

int main() {
    fd_set readfds;
    struct timeval timeout;
    int maxfd = 10;
    
    while (1) {
        FD_ZERO(&readfds);
        FD_SET(listen_fd, &readfds);
        FD_SET(client_fd_1, &readfds);
        FD_SET(client_fd_2, &readfds);
        // 集中设置本次要监视的所有 fd
        
        timeout.tv_sec = 5;
        timeout.tv_usec = 0;   // 每个循环都重新设置 timeout，
                               // 因为 select 返回后 timeout 会被改写为剩余时间
        
        int ret = select(maxfd + 1, &readfds, NULL, NULL, &timeout);
        if (ret == -1) {
            // 处理错误
        } else if (ret == 0) {
            // 超时
        } else {
            if (FD_ISSET(listen_fd, &readfds)) {
                // 有新连接
            }
            if (FD_ISSET(client_fd_1, &readfds)) {
                // client_fd_1 可读
            }
        }
    }
    return 0;
}

注意上面对 timeout 的处理。很多人第一次写 select 都会踩这个坑：timeout 没放到循环里初始化，结果第二次循环超时时间变成奇怪的值或者立即返回。原因是 Linux 内核会修改你传入的 timeval 结构体，把剩余时间写回去。这不是 bug，是文档里写了但很多人不细看的行为。

1.2 maxfd 参数与 1024 限制的真实理解

select(nfds, ...) 的第一个参数 nfds 应该是“最大 fd 编号 + 1”，不是 fd 的个数。这俩特别容易被搞混。假设你的 socket fd 是 200，最大 fd 编号就是 200，那 nfds 要传 201，内核才能遍历到 0~200 这 201 个位置。如果你只有 10 个连接但 maxfd 传了 10，内核压根不会检查编号大于等于 10 的 fd——虽然它们也在集合里，但不会被检查。反过来说，如果你的 fd 编号是 500，nfds 传 100，那么 fd 500 即使 FD_SET 了也白搭。这种 bug 非常隐蔽，因为不报错，只是连接那边永远收不到事件。

都知道 select 有 1024 的容量上限（默认 FD_SETSIZE 是 1024），但理解要再深一层：这个限制是 ** 用户态 fd_set 位图决定的**。fd_set 其实就是一个位图数组，FD_SET(fd, &set) 就是把这个位图的第 fd 位比特置 1。位图总共 1024 位，所以 fd 编号 0-1023 可以，1024 就不行了。这里有个隐藏的常量，Linux 2.6 之后你可以在包含 sys/select.h 之前 #define FD_SETSIZE 2048，手动把上限调高，然后再把用户态的位图大小同步过去。但注意，** 内核里还有个 watch_queue 的大小限制，这也不是把 FD_SETSIZE 改了就能完全绕开的**，真正生产环境超过 1024 连接，务实的选择是直接上 poll 或 epoll，别和 select 纠缠。

1.3 三个容易翻车的经典问题

第一个是 accept 和 select 之间的竞态。当监听 socket 有连接请求时，select 会把它标记为可读，但等你真正去 accept 的时候，这个连接可能已经被客户端断开，accept 返回 EMFILE 或者 ECONNABORTED。如果你写的代码是接到可读事件就立刻 accept 并且不处理失败返回值，连接稍微多点，日志里就会出现一堆异常。常规做法是 accept 之前先判断 errno，或者干脆把 accept 包裹在循环里，遇到 EMFILE 时先 close 一个空闲 fd 再继续。

第二个是 fd 复用带来的假事件。假设客户端 A 断开，你 close 了它的 fd，比如 fd 是 9。然后同一个进程里，下一个新连接恰好也被分配了 fd 9。而这个 fd 9 还残留在 select 的下一次监视集合里，没被清理干净。select 返回后，你以为 fd 9 是之前那个断开的客户端，其实它已经变成新连接。这种问题最折磨人，表现是消息“串号”或读到莫名其妙的残留数据。解决办法只有一条：每次 close 一个 fd，在所有集合里删掉它，并从业务层面标记这个连接已死。

第三个是 信号中断导致 select 返回 -1。大部分网络服务里会用到 SIGTERM、SIGINT 做优雅退出，或者用了 SIGPIPE 做处理。当 select 阻塞时收到信号，它会直接返回 -1，errno 是 EINTR。如果你不做判断直接退出循环，服务就挂了；如果你不判断直接重新进入 select，那么原本的信号处理逻辑就丢了。生产代码里这行判断是必须的：

c复制if (ret == -1 && errno == EINTR) {
    continue;  // 重新进入 select
}

1.4 你什么时候该选 select

说实话，在 2024 年写新项目，我基本不会选 select。但有一种情况是例外：你在做跨平台的小工具，或者目标环境是某些老系统，不支持 epoll 和 kqueue，只有 select 可选。碰到这种场景，select 反而是最稳的。另一个适用场景是连接数极少并且逻辑极简的管理通道，比如某个服务内部的健康检查端口，select 足够，杀鸡不必用牛刀。

2. poll：一次不够彻底的升级

poll 在 1997 年就进了 Linux，设计目标就是改掉 select 的几个痛点：取消 1024 上限、不再修改传入的集合、把关注事件和发生事件分开。这些目标确实达到了，但 poll 的性能模型和 select 没有本质区别——都是线性扫描，连接数一上来照样拉胯。

2.1 pollfd 结构：用数组替代位图

poll 的核心是 pollfd 数组：

c复制struct pollfd {
    int fd;         // 你要监视的文件描述符
    short events;   // 你关心的事件：POLLIN、POLLOUT、POLLERR 等
    short revents;  // 内核反馈的事件：发生的事件填在这里
};

这个结构体最大的价值在于 events 和 revents 分离。select 里你每次要重建 fd_set，poll 里你只需要在连接状态变化时修改对应 pollfd 数组元素的 fd 值和 events 字段。内核填充 revents，不会破坏你设置好的 events，下一次调用直接复用这个数组就行。

c复制#include <poll.h>

// 假设 fds 是一个动态数组，fds[0] 用于监听 socket
struct pollfd *fds;
int nfds = 1;

fds = calloc(MAX_CONN, sizeof(struct pollfd));
fds[0].fd = listen_fd;
fds[0].events = POLLIN;

while (1) {
    int timeout = 5000;  // poll 的 timeout 单位是毫秒
    int ret = poll(fds, nfds, timeout);
    if (ret < 0) {
        if (errno == EINTR) continue;
        break;
    }
    if (ret == 0) {
        // 超时，做定时任务
        continue;
    }
    
    // 遍历数组
    for (int i = 0; i < nfds; i++) {
        if (fds[i].revents & POLLIN) {
            if (fds[i].fd == listen_fd) {
                // 有新连接
                int new_fd = accept(listen_fd, NULL, NULL);
                fds[nfds].fd = new_fd;
                fds[nfds].events = POLLIN;
                nfds++;
            } else {
                // 普通连接可读
            }
        }
        // 注意：POLLERR、POLLHUP、POLLNVAL 这三个要单独处理
        if (fds[i].revents & (POLLERR | POLLHUP | POLLNVAL)) {
            // 关闭连接，从数组中移除该元素
        }
    }
}

2.2 POLLIN、POLLHUP 和 POLLNVAL 的角力

这里要点名一个新手很容易漏掉的地方：poll 返回的 revents 里，POLLIN 并不能覆盖全部出错情况。当对端关闭时，poll 可能返回 POLLIN（告诉你还有数据可读，读完之后才返回 0），也可能返回 POLLHUP 或 POLLERR。如果你代码里只写了 if (revents & POLLIN)，就会出现一个连接已经断开但你没有感知，一直等到超时才处理的情况。我团队里有人写过这样的代码，线上表现就是连接池里一堆死链接占用 fd。

规范写法是把这些事件全列出来逐个判断，而且在业务层面优先处理 POLLHUP/POLLERR/POLLNVAL，再处理 POLLIN/POLLOUT。原因很简单：如果连接已经异常，你再去读数据很可能读到的是垃圾或触发错误，先关掉是最稳的。

POLLNVAL 这个值特别有意思，它表示“fd 未打开”。如果你不小心把一个负数或者非法的 fd 塞进了 poll 数组，内核会直接给你回 POLLNVAL。我遇到过的真实场景：并发请求下，某个连接先被另一个线程关闭，而 poll 数组还没清理干净，poll 就返回 POLLNVAL。你把 errno 打出来看，它是 0，但 revents 里有 POLLNVAL——这种“无 errno 的错误”最坑，排查起来毫无头绪。

2.3 动态扩容的坑

poll 用数组存 pollfd，意味着你要自己管理数组大小。最朴素的思路是开固定大小，比如 MAX_CONN = 1024，不够就报错。但高并发下这显然不行，所以一般会做动态扩容。扩容本身不难，但有个细节：旧的 pollfd 数组里的 fd 和 events 必须原样拷贝到新数组，revents 字段可以直接丢弃。revents 是内核填充的，下一次 poll 调用会重新填充，拷贝旧值是纯浪费。

扩容的逻辑得放在循环之外。你在 poll 返回后、遍历数组之前，先扫描一遍数组看哪些元素已经没必要保留（fd = -1 是常用的标记方式），压缩数组长度，腾出空间给新连接。如果你在 poll 调用期间动态 realloc 数组，会导致 poll 内部的数组指针失效，轻则返回异常，重则直接段错误。

2.4 为什么 poll 还不够

poll 对比 select 的提升主要在易用性和容量上，性能上依然不尽如人意。原因一句话就能说透：每次调用 poll，内核要把用户态的 pollfd 数组完整拷贝到内核态，然后线性扫描一遍全部 fd，找出有事件的 fd，再把结果拷回用户态。这个过程是 O(n) 的，n 是监视的 fd 总数。连接数一上到几千，这个 O(n) 的拷贝和扫描就会占掉大量 CPU。

另一个问题是孤悬的“活跃度探测”。poll 没有“只返回有事件的那个”的能力，所以你的用户态代码也要遍历整个数组，哪怕只有 1 个 fd 有事件，你也要扫描几千个元素才知道是谁。对 1 万个连接，用户态一次遍历也是 1 万次操作，累计下来开销不小。

所以 poll 在我的项目里定位很清晰：适合连接数在几百到一千左右、且对延迟不敏感的场景。再往上走，就该 epoll 出场了。

3. epoll：Linux 高性能网络服务的事实标准

从 poll 到 epoll，不是修补补丁，而是设计思路上的彻底转向。select/poll 是“我帮你把所有 fd 看一遍，告诉你哪些有事件”，epoll 是“你把 fd 交给我，有事件我主动告诉你”。后者不再依赖轮询，而是采用事件驱动 + 回调机制。

3.1 三个系统调用和一个隐藏的数据结构

epoll 全套只有三个函数：epoll_create1、epoll_ctl、epoll_wait。用起来极简，但背后藏着一个内核里的关键结构——epitem。每个添加到 epoll 的 fd 都会在内核里生成一个 epitem 节点，这个节点挂在红黑树上，同时通过回调机制注册到 socket 自己的等待队列里。

c复制#include <sys/epoll.h>

int epfd = epoll_create1(0);   // 创建 epoll 实例
                               // 0 表示默认行为，EPOLL_CLOEXEC 用于多线程/fork 场景

struct epoll_event ev;
ev.events = EPOLLIN;          // 监视可读事件
ev.data.fd = listen_fd;        // 携带的信息，通常是 fd 或指针
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

struct epoll_event events[128];
int timeout = 1000;            // 单位也是毫秒
int n = epoll_wait(epfd, events, 128, timeout);
for (int i = 0; i < n; i++) {
    int fd = events[i].data.fd;
    uint32_t ev_type = events[i].events;
    // 处理 fd 上的事件
}

这里解释一下为什么 epoll 在高并发下效率远超 select/poll：当 socket 上有数据到达时，内核会直接找到对应 epitem 的回调函数，把就绪的 fd 插到 epoll 实例的就绪链表里，这个操作不是扫描全量 fd，而是精准的事件推送。epoll_wait 做的事，只是把就绪链表里的内容拷贝到用户态数组，拷贝量跟“实际有事件的 fd 数”成正比，而不是跟“监视的 fd 总数”成正比。这就是 epoll 处理海量连接的核心优势。

3.2 LT 和 ET：阻性与边缘的决择

epoll 有且仅有两个工作模式：水平触发（LT）和边缘触发（ET）。这个选择会影响你后续所有代码的写法，必须在业务开发前想清楚。

**水平触发（LT）**是默认模式，也是 select/poll 唯一的工作方式。它的特性是：只要 fd 上还有数据没读完，每次 epoll_wait 都会返回这个 fd。举例：一个 fd 的可读缓冲区里有 100 字节，你只 read 了 50 字节，下一次 epoll_wait 依然会返回这个 fd 可读。这种模式容错率高，代码写起来也不容易出问题。你读多读少都不会“丢事件”，因为你没读完数据，事件就会一直触发。

**边缘触发（ET）**则完全不同。它只在 fd 状态发生变化的那一刻通知一次。还是那个 100 字节的例子：数据到达时，epoll_wait 返回这个 fd 可读，你只读了 50 字节，下一次 epoll_wait 不会再返回这个 fd——除非有新的数据再进来（状态再次从“无数据”变为“有数据”）。这意味着你必须在一次通知里把数据尽可能读完，否则就会发生数据滞留在内核缓冲区没人处理的情况。

c复制// ET 模式的标准设置
struct epoll_event ev;
ev.events = EPOLLIN | EPOLLET;  // 核心：加上 EPOLLET 标志
ev.data.fd = client_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);

// ET 模式的处理要义：循环 read 直到 EAGAIN
int read_data(int fd, char *buf, int len) {
    int total = 0;
    while (1) {
        int n = read(fd, buf + total, len - total);
        if (n == -1) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                break;  // 数据读完了，正常退出
            }
            // 其他错误，比如 ECONNRESET，需要关闭连接
            return -1;
        }
        if (n == 0) {
            // 对端关闭连接
            close(fd);
            return 0;
        }
        total += n;
        if (total >= len) break;
    }
    return total;
}

ET 模式的高明之处在于减少了内核态到用户态的事件通知次数。同样是 100 字节分 100 次到达，LT 模式可能触发 100 次；ET 模式下，只要这些数据在第一次状态变化后陆续到达，事件的“状态变化”只有一次，后续数据到达时，socket 已经是“有数据”状态，不会再触发新的通知。你一次 read 循环把它全读完就行。ET 的性能优势在这种高频小包场景尤其明显。

3.3 实战：LT 模式下的完整 TCP echo 服务

先给一个 LT 模式的服务端核心代码。LT 模式的理解门槛低，适合作为初版实现。

c复制#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/epoll.h>

#define MAX_EVENTS 64
#define BUF_SIZE 4096

int main() {
    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    int opt = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_port = htons(8080);
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr));
    listen(listen_fd, 64);

    int epfd = epoll_create1(0);
    struct epoll_event ev;
    ev.events = EPOLLIN;
    ev.data.fd = listen_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

    struct epoll_event events[MAX_EVENTS];
    char buf[BUF_SIZE];

    while (1) {
        int nready = epoll_wait(epfd, events, MAX_EVENTS, -1);
        for (int i = 0; i < nready; i++) {
            if (events[i].data.fd == listen_fd) {
                // 处理新连接
                int client_fd = accept(listen_fd, NULL, NULL);
                if (client_fd < 0) {
                    // 非阻塞 accept 时注意 EAGAIN
                    continue;
                }
                ev.events = EPOLLIN;
                ev.data.fd = client_fd;
                epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);
            } else {
                int fd = events[i].data.fd;
                int n = read(fd, buf, BUF_SIZE);
                if (n <= 0) {
                    // 0 表示对端关闭，负值表示出错
                    close(fd);
                    epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
                } else {
                    // 原样写回
                    write(fd, buf, n);
                }
            }
        }
    }
    close(epfd);
    close(listen_fd);
    return 0;
}

这段代码核心逻辑是：监听 socket 有事件就 accept 新连接，普通 fd 有事件就 read 再 write。LT 模式下，read 不需要循环读到 EAGAIN，因为哪怕没读完，内核还会再次通知你，大不了下次继续读。这是 LT 的容错红利。

但这段代码有隐藏缺陷：它没有处理 EPOLLOUT。考虑一个极端情况：客户端读数据很慢，服务端 write 一个很大的响应，socket 发送缓冲区写满了，write 返回 EAGAIN，数据没发完。如果代码没有处理 EPOLLOUT，数据就一直卡在应用层缓冲区里，发送超时，连接最终断开。生产级代码必须考虑这种情况。

3.4 实战：ET 模式下的完整处理框架

ET 模式下代码最明显的变化有三处：所有 fd 必须是非阻塞的、read 必须循环到 EAGAIN、accept 也要循环到 EAGAIN。先看非阻塞怎么设置：

c复制int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

这两个系统调用每个新 fd 都要执行。然后是 accept 的处理：

c复制// ET 模式下，listen_fd 必须设为非阻塞
while (1) {
    int client_fd = accept(listen_fd, NULL, NULL);
    if (client_fd < 0) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            break;  // 本次已把所有待处理的连接都 accept 完了
        }
        // EMFILE 等错误单独处理
        break;
    }
    // 设置新 fd 非阻塞
    set_nonblock(client_fd);
    // 加入 epoll，注意监听模式
    ev.events = EPOLLIN | EPOLLET;
    ev.data.fd = client_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);
}

为什么要循环 accept 到 EAGAIN？因为 ET 模式下，如果有多个连接同时到达，listen_fd 的状态从“无连接”变为“有连接”只会通知一次。你只 accept 一个就回去等下一次通知，剩下的连接就躺 backlog 队列里无人问津，客户端那边表现为“连上了但服务端没反应”。所以必须一次性把所有 pending 的连接取完。

ET 模式下 read 逻辑也要跟着改，用前面写的 read_data 或类似逻辑，循环读直到 EAGAIN。同样的道理，ET 模式下处理 EPOLLOUT 时，发送数据也要循环写直到 EAGAIN，如果有数据没写完，要注册 EPOLLOUT 事件，等下次可写通知后再继续写：

c复制// 发送缓冲区满时，注册写事件
if (n < len) {
    // 把剩余数据保存到应用层发送队列
    append_to_send_queue(fd, buf + n, len - n);
    ev.events = EPOLLIN | EPOLLET | EPOLLOUT;
    ev.data.fd = fd;
    epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
}

3.5 epoll 事件处理的完整字段检查

不管 LT 还是 ET，你的事件检查必须完整。实际生产中，除了 EPOLLIN 和 EPOLLOUT，我还强烈建议把 EPOLLERR、EPOLLHUP、EPOLLRDHUP 全部纳入检查范围。

EPOLLERR 表示 fd 发生错误，比如 TCP 连接收到 RST 段；EPOLLHUP 表示对端挂断；EPOLLRDHUP 比较特殊，是 Linux 2.6.17 之后新增的，表示“对端关闭了写半段”（shutdown(SHUT_WR)），这时候你还能从 fd 里读出数据，读完后收到 EOF。这三个事件如果不单独处理，你会在 epoll_wait 返回后陷入莫名其妙的读错状态。

正确的顺序：先检查错误类事件，再检查读写事件。

c复制if (events[i].events & (EPOLLERR | EPOLLHUP)) {
    close(fd);
    epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
    continue;
}
if (events[i].events & EPOLLRDHUP) {
    // 对端写半关闭，标记连接准备关闭
    // 但还能读数据，不能立刻 close
}
if (events[i].events & EPOLLIN) {
    read_and_handle(fd);
}
if (events[i].events & EPOLLOUT) {
    flush_send_queue(fd);
}

4. 三者在真实场景下的实测对比与选型

代码写得再多，不如实测数据有说服力。我去年在某公司做过一个模拟网关的压测实验，环境是 4 核 8G 的虚拟机，客户端用多线程模拟几千个并发连接同时发送小包。下面是三种方案在没有业务逻辑损耗、纯 echo 场景下的数据（每组实验跑 5 分钟取均值）：

结论很直白：

• 连接数 < 100：三者差别不大，选你最熟的就行。
• 连接数 100~1000：poll 和 epoll 都能用，但 epoll 已经开始展示优势。
• 连接数 > 1000：只有 epoll 稳定，select 首先出局。
• 连接数 > 5000：ET 模式的优势完全释放，LT 模式 CPU 占用明显更高。

还有一个容易忽略的数据：事件通知次数。同样 100 个连接持续发送小包，LT 模式下 epoll_wait 的返回次数大约是 ET 模式的 2 到 3 倍。原因前面解释过：LT 只要数据没读完就会反复通知，ET 只在状态变化时通知一次。

4.1 从 CPU 缓存和内存拷贝角度理解差距

为什么 select/poll 在并发上去之后 CPU 消耗会陡增？这里不只看算法复杂度，还得看硬件层面的行为。select 和 poll 每次调用都要把整个 fd 集合从用户态拷贝到内核态，监听 1 万个 fd 就拷贝 1 万份。这个拷贝本身就是内存带宽消耗。然后内核线性扫描这 1 万个 fd，每个 fd 的检查涉及链表遍历和位操作，CPU 缓存命中率会随着 fd 数量增长而下降。

epoll 的聪明之处是把 fd 留在内核里，红黑树存储，增删改查复杂度 O(log n)，而就绪通知是回调驱动的，不需要每次全量扫描。用户态和内核态之间只传“实际有事件”的 fd。连接多、但同时活跃的连接少时，这个差距会放大到数量级。

4.2 选型建议：别为了 ET 而 ET

我见过团队里有人为了“秀技术”给所有服务都上 ET，结果代码里到处是 EAGAIN 处理、事件循环重入的管理，bug 量直线上升。我的实际建议分场景：

• ** 客户端数量少（<500）、包都比较小、逻辑简单**：LT 模式，代码清晰，维护成本最低。
• ** 客户端数量大（数万）、连接的活跃度不均衡**：ET 模式，性能优势明显。
• ** 高并发 + 文件传输或大块数据读写**：ET 模式 + 非阻塞 IO，几乎是必须的，否则 LT 反复通知会造成大量无效的 epoll_wait 返回。
• ** 网关、代理、流量转发类**：优先 ET，转发场景下每个连接都频繁有数据，状态变化频繁，正好发挥 ET 的优势。

还有一个折中方案：混合模式。监听 socket 用 ET（连接事件不密集，ET 压力不大），普通数据 fd 用 LT（简化读写逻辑）。我写过几个中等规模的服务，都是这样干的，收益明显。

5. 实践中的高级技巧与问题排查

理论讲得再好，碰到真实场景还是会翻车。下面是几个我压箱底的经验，每一个都对应一个至少线上故障级的坑。

5.1 EPOLL_CTL_MOD 的丢失更新问题

epoll_ctl 的 MOD 操作是拿你传入的 event 结构体整体覆盖该 fd 的注册信息。假如初始注册是 EPOLLIN，后来因为发送队列满，你想改注册 EPOLLOUT，正确写法是：

c复制ev.events = EPOLLIN | EPOLLOUT;   // 注意，不是只写 EPOLLOUT
ev.data.fd = fd;
epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);

如果只写 EPOLLOUT，那么以后这个 fd 上有数据可读时，内核不再触发可读事件，因为可读事件已经被你覆盖掉了。这种 bug 的典型表现是：程序运行一段时间后，某些连接不再响应新数据，要等下一次 EPOLLOUT 事件到来时才捎带处理，排查起来非常有迷惑性。

5.2 accept 返回 EMFILE 时的保命策略

EMFILE 表示进程的 fd 数量达到上限（ulimit -n）。这个错误发生场景很特别：你监听的高峰期，fd 恰好耗尽，又有新连接进来。此时如果直接忽略，那 backlog 队列会一直堆积，更糟的是 监听 fd 会持续触发 EPOLLIN，导致 epoll_wait 忙循环，CPU 被空转吃满。我遇到过一次，现场表现为 CPU 100% 但业务毫无流量。

保命策略分两步。第一，提高进程的 fd 上限：

bash复制ulimit -n 655350

第二，在代码里专门处理 EMFILE。有一个经典技巧：准备一个备用 fd。进程启动时先 open 一个 /dev/null 拿到 fd，当 accept 返回 EMFILE 时，先 close 掉这个备用 fd，空出一个 fd 位，然后 accept 那个待处理的连接，拿到 fd 后立刻 close 它（丢掉这个连接），再重新 open /dev/null 把备用 fd 补回来。这样做的目的是让监听 socket 的 backlog 队列被清空，避免 epoll_wait 忙循环。

c复制if (client_fd < 0) {
    if (errno == EMFILE) {
        close(spare_fd);
        int tmp_fd = accept(listen_fd, NULL, NULL);
        close(tmp_fd);
        spare_fd = open("/dev/null", O_RDONLY);
        continue;
    }
}

5.3 惊群问题与 EPOLLEXCLUSIVE

传统的 accept 惊群是这样的：多个进程/线程都阻塞在 epoll_wait 上监听同一个 listen_fd，当一个新连接到达时，所有等待者都被唤醒，但只有一个能 accept 成功，其他进程空跑一圈。Linux 4.5 加入的 EPOLLEXCLUSIVE 可以解决这个问题：用这个标志注册事件后，内核只唤醒等待队列中的一个等待者。

想要用的场景通常是 多进程配合 reuseport 的模式。比如：

c复制ev.events = EPOLLIN | EPOLLEXCLUSIVE;
epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

但注意 EPOLLEXCLUSIVE 只支持被唤醒者，不支持作为事件标志传给 epoll_wait 返回的事件结构，用了也不会报错，只是没意义。

5.4 多线程 epoll 的正确姿势

epoll 本身线程安全，同一个 epoll 实例可以多个线程同时调 epoll_wait。但代码逻辑上有个大坑：如果一个连接被两个线程同时操作（一个正在阻塞 read，另一个在 epoll_ctl MOD 注册新事件），数据竞争和 fd 错乱是大概率事件。我的建议是：

• 最简单的方案：单线程事件循环 + 业务处理线程池。事件循环只负责收发数据，耗时的业务逻辑丢给线程池。
• 次简单方案：多线程各持独立 epoll 实例，线程之间通过管道消息传递 fd。注意跨线程传递 fd 要用 sendmsg 的 SCM_RIGHTS 机制，不能简单把 int 值传过去直接读写。
• 不推荐的方案：共享同一 epoll 实例的多线程同时 epoll_wait。你们团队如果不是对代码把控能力很强，别碰这种设计。

5.5 边缘触发的坑：read 循环的边界条件

ET 模式 read 循环里最坑的一点：缓冲区大小。你分配的 buf 是 4096，但内核缓冲区里可能有 1MB 数据。一次循环里 read 满了 4096 就退出，剩下的数据因为不会再触发 EPOLLIN，就会一直滞留。我之前一个同事写的代码就有这问题：固定 4KB 缓冲，客户端一次性发 100KB 数据，服务端只处理了 4096 字节，剩余数据在缓冲区里躺尸，客户端迟迟等不到响应。最后调大缓冲 + 在循环里判断 read 返回值小于 buf 剩余空间时才退出，才算解决。

正确做法是：read 循环里，只有当返回值小于请求的 size、或返回 EAGAIN 时，才能退出循环。如果每次 read 都读满 buf，说明缓冲区里可能还有数据，要继续读。

5.6 仔细处理 EPOLLOUT 的注册与清理

EPOLLOUT 事件只应在“发送队列非空”时注册，发送队列清空后立刻移除。如果不移除，会出现什么现象？socket 发送缓冲区一旦有空位，内核就通知 EPOLLOUT，你的程序就会陷入无限循环的写事件处理，CPU 瞬间爆表。典型表现：服务启动后 CPU 状态满，但实际 qps 寥寥。

清理方式：

c复制if (send_queue_empty(fd)) {
    ev.events = EPOLLIN | EPOLLET;  // 去掉 EPOLLOUT
    ev.data.fd = fd;
    epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
}

这个 MOD 操作会带着 EPOLLIN 一起传，保证读事件不被覆盖。

5.7 从 SIGPIPE 说起：网络编程的稳定性细节

写 socket 时，如果对端已经关闭连接，你继续 write 会触发 SIGPIPE 信号，默认行为是终止进程。服务端高并发下这是致命问题：一个不稳定的客户端可以直接把你的服务搞挂。标准解法：

c复制// 忽略 SIGPIPE，让 write 返回 EPIPE
signal(SIGPIPE, SIG_IGN);

或者更可靠的方式，在编译时加入：

c复制#include <signal.h>

// 或使用 send 的 MSG_NOSIGNAL 标志
ssize_t n = send(fd, buf, len, MSG_NOSIGNAL);

这里有个细节值得说明：signal(SIGPIPE, SIG_IGN) 是进程级设置，配置一次全局生效；而 MSG_NOSIGNAL 是调用级设置，每个 send 都要加标志。两者各有适用场景，我通常两种都做，双保险。

5.8 大并发场景下的 epoll_wait 超时策略

epoll_wait 的 timeout 参数很多人随手写 -1（永久阻塞）或 0（立即返回）。-1 的问题在于，如果你有定时器任务（心跳包、连接超时回收），永久阻塞的 epoll_wait 会让定时器饿死，必须在别的线程里跑定时器。0 的问题则是忙轮询，CPU 空转。我建议的折中：

• 心跳周期 30 秒的场景：timeout 设 1000ms，循环内顺手做定时任务。
• 纯粹转发场景、无定时任务：-1 永久阻塞，省 CPU。
• 需要快速响应外部信号或控制命令：timeout 设 100ms，每次循环检查控制标志。

6. 写在最后的几条实战心得

这些心得没有固定的顺序，都是我在具体项目里踩过坑之后提炼出来的判断，信不信看完你自会有结论。

第一个心得：网络编程出 bug 往往是逻辑问题，不是 API 问题。select/poll/epoll 的 API 就那么多，翻来覆去就那些函数，真正让你头疼的是连接状态的管理、缓冲区生命周期的控制、事件循环和业务逻辑之间的协作。我调试过无数“偶发死连接”的案例，最后根因几乎都在于 fd 生命周期管理混乱：某个模块 close 了一个 fd，另一个模块还在用它注册事件，或者两个模块同时操作同一个 fd。建议在项目里维护一张 fd 归属表：fd 是哪一层负责关闭的、目前注册了哪些事件、应用层缓冲区的状态是什么，一目了然。

第二个心得：先做对，再谈性能优化。我见过有人一上来就写 ET 模式 + 各种旁路缓存 + 无锁队列，最后代码 review 的时候发现自己连 epoll_wait 的返回事件分类都没理清楚。网络编程的性能优化本身逻辑复杂，如果基础的正确性都不能保证，优化带来的收益会被 debug 成本吃掉。新建项目先用 LT 模式 + 同步阻塞逻辑跑通全流程，等稳定了，再逐模块切换到 ET 模式并做性能压测对比。

第三个心得：工具链比你想的更重要。排查网络问题全靠 tcpdump、strace、gdb、perf 这几样。strace 看系统调用和返回值，tcpdump 看包级别行为，perf 看 CPU 热点函数，gdb 定位代码崩溃位置。特别是排查 epoll 相关问题时，strace -f -e epoll_ctl,epoll_wait -p <pid> 能看到你加了哪些 fd、注册了哪些事件、等待返回了哪些事件，几乎所有“事件为什么没触发”的问题都能从这里找到线索。

第四个心得：压测要模拟真实场景。很多人压测都是并发发固定大小、固定频率的包，这种测试结果参考价值有限。真实场景里，连接会拨入拨出、数据包有大有小、有突发有沉寂。我习惯用随机化的压测脚本：随机连接数、随机包大小、随机延迟间隔，把服务往死里折腾，才能暴露出真实的资源泄露和事件竞争问题。

以上。这算是对上一篇基础文章的补充延展，也是我在多个网络模块项目里反复验证过的方法。如果你正在从 select/poll 往 epoll 迁移，或者正在纠结要不要上 ET 模式，希望这篇内容能帮你节省几个晚上的排查时间。