epoll高并发TCP服务器实战：从原理到代码的完整指南

两年前我接手一个内部服务，原方案用的是“每来一个连接就开一个线程”的模式。连接数少的时候还好，等并发跑到三百多，线程频繁创建销毁，CPU 飙高，内存涨得飞快，最后进程直接僵死。当时我花了一个晚上把核心模块改成 epoll 驱动的 TCP 并发服务器，同一台机器，压到三千连接依旧稳得很，CPU 占用还降了一半。从那以后，凡是要做高并发 TCP 服务，我第一个想到的方案就是 epoll。

这篇文章会把 epoll 的原理、核心 API、触发模式、完整代码以及我在实际调试中踩过的坑从头到尾过一遍。适合刚接触 Linux 网络编程的开发者，也适合在传统多线程模型上吃够了苦头、想换事件驱动思路的工程师。你可以直接照着代码改，也可以只读设计思路，然后迁移到自己的项目里。

1. 并发服务器模型：从阻塞I/O到epoll事件驱动

1.1 经典模型的痛点在哪里

先看学校里最常教的“多线程 TCP 服务器”。主线程 accept 一个连接，就创建一个线程去处理这个连接的读写。逻辑很直接，但对高并发场景来说问题非常明显。

第一，线程是有成本的。创建一个线程默认栈空间是 8MB（虚拟内存），虽然实际物理内存按需分配，但上千个线程光上下文切换就能让 CPU 疲于奔命。第二，阻塞 I/O 会浪费 CPU。线程在 recv 等数据的时候是阻塞挂起的，这个等待期间 CPU 什么都没干。连接越多，浪费越严重。

有人会说，那我用非阻塞 I/O + 轮询行不行？轮询没问题，但在应用层对每个连接循环调用 recv，大部分调用都会返回 EAGAIN，这是典型的用户态空转，白白消耗 CPU。

select 和 poll 的出现解决了一部分问题，但它们的核心缺陷依然存在：每次调用都要把全部 fd 集合从用户态拷贝到内核态，内核再线性扫描一遍找出就绪的 fd，扫描完再拷贝回用户态。连接数一多，这个 O(n) 的拷贝加扫描就成了瓶颈。

1.2 select和poll的具体瓶颈

select 有个硬限制，FD_SETSIZE 默认是 1024，也就是说最多监听 1024 个 fd。虽然可以改宏重新编译内核，但本质上还是线性扫描的方式，治标不治本。

poll 去掉了 1024 的限制，用 pollfd 数组来管理 fd。但它依然存在两个问题：

• 每次调用 poll 时，要把全部 fd 从用户态拷贝到内核态，调用结束后再拷贝回用户态。假设有一万个连接，其中只有两个就绪，那这一万次拷贝里百分之九十九点九都是无用功。
• 内核在 poll 内部也是遍历整个 fd 数组来检查每个 fd 的状态。连接越多，遍历越慢。

你可以把 select/poll 想象成一个客服，每天上班第一件事就是挨个打电话问一百个客户“你有事吗”，问完一圈只有两个客户说有事。这个效率可想而知。

1.3 epoll的机制为什么高效

epoll 的思路完全不同。它把“我要监听哪些 fd”提前告诉内核，内核维护一个事件表。当某个 fd 上有事件发生时，内核通过回调机制把对应的 fd 加入到就绪链表。调用 epoll_wait 时，只需要把就绪链表里的 fd 拷贝到用户态就行。

也就是说，epoll 在“告诉我哪些 fd 有事件”这一步做到了 O(1)，而不是 O(n)。内核在底层通过红黑树管理需要监听的 fd，增删改查都是对数级别，即使连接数量很大也能扛住。

另外一个关键点，epoll 不像 select/poll 那样每次调用都要重建监听列表。fd 集合在内核中持续存在，只有调用 epoll_ctl 增删改时才需要更新。这种设计天然适合“连接只在某几个时间点建立和断开，大多数时间都在等待读写”的服务器场景。

用一句话来记忆：select 是“每次我都问你一遍”，epoll 是“你有事再通知我”。这就是事件驱动和轮询的本质区别。

2. epoll核心API与两种触发模式

2.1 三个核心函数

epoll 的使用围绕三个函数展开。

epoll_create1 用来创建一个 epoll 实例，返回一个文件描述符。早期版本是 epoll_create(int size)，size 参数被忽略了但必须大于 0。新版建议直接用 epoll_create1(0)，如果加上 EPOLL_CLOEXEC 标志，可以在 exec 时自动关闭这个 fd，避免子进程意外继承。

c复制int epfd = epoll_create1(0);
if (epfd == -1) {
    perror("epoll_create1");
    exit(EXIT_FAILURE);
}

epoll_ctl 用来对 epoll 实例做增删改操作。

c复制struct epoll_event ev;
ev.events = EPOLLIN;
ev.data.fd = client_fd;
int ret = epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);

三个操作类型要记清楚：EPOLL_CTL_ADD 添加一个新的 fd 到监听表；EPOLL_CTL_MOD 修改一个已有 fd 的关注事件；EPOLL_CTL_DEL 把一个 fd 从监听表中移除。

epoll_wait 是阻塞等待事件发生的函数。

c复制struct epoll_event events[1024];
int n = epoll_wait(epfd, events, 1024, -1);
for (int i = 0; i < n; i++) {
    // 处理 events[i]
}

timeout 参数是超时毫秒数，-1 表示无限等待。返回值 n 是本次就绪的事件个数，遍历 events 数组前面的 n 项即可。

2.2 LT和ET到底有什么区别

LT 是水平触发，是默认模式；ET 是边缘触发，需要在注册事件时加上 EPOLLET 标志。

用门铃来类比：门铃响了一次，你没有开门。LT 模式下，只要门铃事件没有处理完，门铃会一直响，提醒你“还有事没处理”；ET 模式下，门铃只在状态变化的那一刻响一次，如果你没处理，之后不会再响，除非状态再次变化。

具体到代码层面：

• LT 模式下，只要 socket 接收缓冲区里有数据，epoll_wait 就会一直返回 EPOLLIN 事件。这种模式不容易丢数据，比较适合新手。
• ET 模式下，只有当缓冲区从无数据变成有数据的那一刻，epoll_wait 才会返回一次 EPOLLIN 事件。如果你只 read 了一次，缓冲区可能还剩数据，但内核不会再通知你了，必须一次性把所有数据读完，也就是循环 read 直到返回 EAGAIN。

ET 模式的优点是不会频繁触发，性能更高；缺点是要求程序员对事件处理非常严谨，少读一次就丢数据。

我的经验是，刚开始用 epoll 时先用 LT，代码简单、不容易出错。等项目跑通、理解了数据流，再切换到 ET 模式做优化。生产环境我最终用的是 ET 模式，但前提是代码里对读循环处理得非常仔细。

2.3 需要关注的事件类型

epoll_event 的 events 字段可以组合多种事件，最常用的有几个：

• EPOLLIN：可读事件，包括对端关闭连接的情况（此时 read 返回 0）
• EPOLLOUT：可写事件，缓冲区从满变为不满时触发
• EPOLLERR：发生错误
• EPOLLHUP：对端挂断
• EPOLLRDHUP：对端关闭连接，这个在 TCP 场景中很有用，可以判断对端关闭而不需要 read 一次才知道
• EPOLLET：边缘触发
• EPOLLONESHOT：一次性通知，触发一次后需要重新注册才能再次收到通知

实际写代码时，EPOLLERR 和 EPOLLHUP 不用特意去注册，epoll 默认就会上报。但处理逻辑里要对这两个事件做出反应，通常是清理 fd 并关闭连接。

3. 完整实现：一个可运行的epoll TCP并发服务器

3.1 整体设计思路

用一个监听 fd 监听 TCP 端口，把它注册到 epoll 实例中。每次 epoll_wait 返回后，遍历就绪事件：

• 如果是监听 fd 的可读事件，说明有新连接进来，调用 accept 接受连接，并把新的客户端 fd 设置为非阻塞，注册到 epoll
• 如果是客户端 fd 的可读事件，调用 read 读取数据，处理数据后调用 write 或 send 返回响应
• 如果是客户端 fd 的可写事件，说明 send buffer 有空余了，可以继续发送之前写不出去的数据
• 如果发生错误或对端关闭，关闭连接，从 epoll 中移除 fd

核心思路就一句话：所有的 I/O 都是非阻塞的，一切靠 epoll 通知来驱动。

3.2 socket初始化的两个关键细节

第一，端口复用必须是第一个设置。不加 SO_REUSEADDR，服务器重启时会报“Address already in use”，这对调试来说是极其恼火的。网上搜“only one usage of each socket address”报错，十有八九就是这个选项没加。

c复制int reuse = 1;
setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

第二，监听 fd 本身也要设置为非阻塞。这点很多人会漏掉。如果监听 fd 是阻塞的，当多个连接同时到达时，accept 只处理了第一个，其他连接在队列里等待，此时如果再来一次 EPOLLIN 事件还能继续 accept。但极端情况下可能出现“accept 返回 EAGAIN 但 epoll 仍然报 EPOLLIN”的情况，所以监听 fd 设置为非阻塞、accept 循环到 EAGAIN 是最稳妥的写法。

初始化流程：

c复制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_addr.s_addr = htonl(INADDR_ANY);
addr.sin_port = htons(8080);

bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr));
listen(listen_fd, 128);

set_nonblocking(listen_fd);

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

backlog 参数我选 128，这只是告诉内核该端口的连接队列上限，真正的并发能力取决于 accept 的速度和事件处理效率。

3.3 accept与读数据循环

事件驱动的服务器，accept 要写成循环：

c复制while (1) {
    int conn_fd = accept(listen_fd, NULL, NULL);
    if (conn_fd == -1) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            break;  // 所有连接都已处理完
        } else {
            perror("accept");
            break;
        }
    }
    set_nonblocking(conn_fd);

    struct epoll_event ev;
    ev.events = EPOLLIN | EPOLLET;  // 边缘触发模式
    ev.data.fd = conn_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
}

这里为什么用循环 accept？因为当监听 fd 可读时，内核只知道“有连接到达”，但不知道有几个。如果不用循环，一次 epoll_wait 只能处理一个连接，剩下的连接要等下一次事件触发。在 ET 模式下，如果只 accept 一次就退出，剩下的连接可能就一直留在队列里得不到处理，造成客户端连接超时。LT 模式因为会持续触发，问题不那么大，但循环 accept 依然是标准写法。

读取数据的循环更加关键，ET 模式下必须一次读完：

c复制char buf[4096];
ssize_t n;
while (1) {
    n = read(fd, buf, sizeof(buf));
    if (n > 0) {
        // 处理数据
        handle_request(fd, buf, n);
    } else if (n == 0) {
        // 对端关闭
        close(fd);
        break;
    } else {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            break;  // 数据读完了
        } else {
            close(fd);
            break;
        }
    }
}

读到 0 表示对端正常关闭了连接，这是 TCP 四次挥手完成后 read 的返回值。读到 -1 且 errno 是 EAGAIN/EWOULDBLOCK，表示当前缓冲区没数据了，这是 ET 模式下正常退出的唯一入口。其他任何 errno 都视为异常，直接关闭连接。

3.4 写数据和连接关闭的处理

很多初学 epoll 的人会忽略 EPOLLOUT 事件，直到在某个高并发场景下遇到性能瓶颈或卡死才开始研究。当你想向一个 socket 写数据但 send buffer 满了，write 会返回 EAGAIN。这时候如果你在同一个线程里循环重试，就是自旋白白消耗 CPU。

正确做法是注册 EPOLLOUT 事件，等内核通知“send buffer 有空间了”再继续写。

具体流程是：

• 调用 send 发送数据，如果返回 EAGAIN，把 fd 的事件从只关注 EPOLLIN 改成同时关注 EPOLLIN | EPOLLOUT，把剩余数据存到应用层的发送缓冲队列
• 等 epoll_wait 返回 EPOLLOUT 事件时，尝试把发送缓冲队列中的数据发出去
• 发送完毕后，如果队列空了，把事件重新改回只关注 EPOLLIN

c复制if (n == -1 && errno == EAGAIN) {
    // 发送缓冲区满，注册 EPOLLOUT
    struct epoll_event ev;
    ev.events = EPOLLIN | EPOLLOUT | EPOLLET;
    ev.data.fd = fd;
    epoll_ctl(epfd, EPOLL_CTL_MOD, fd, &ev);
    // 把剩余数据存到应用层队列
    append_to_send_queue(fd, data, len);
}

在 EPOLLOUT 事件到来时，从队列取数据发送，直到队列清空，再把事件改回 EPOLLIN。这个机制保证了在 send buffer 满的时候不会死等，也不会浪费 CPU 去循环重试。

还有个容易忽略的点：SIGPIPE 信号。当连接的对端已经关闭，你再向这个 socket 写数据，操作系统会发送 SIGPIPE 信号，默认动作是终止进程。一个 CTRL-C 杀不掉的服务器，往往就是这个原因。必须在程序启动时忽略这个信号：

c复制signal(SIGPIPE, SIG_IGN);

3.5 一个可运行的完整示例

下面给一个完整的 echo 服务器，接收 TCP 数据，原样返回，同时支持并发多客户端。这是最简单也是最经典的 epoll 示例。

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>

#define MAX_EVENTS 1024
#define BUFFER_SIZE 4096

static void set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    fcntl(fd, F_SETFL, flags | O_NONBLOCK);
}

int main() {
    signal(SIGPIPE, SIG_IGN);

    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (listen_fd == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    int reuse = 1;
    setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

    struct sockaddr_in addr;
    memset(&addr, 0, sizeof(addr));
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(8888);

    if (bind(listen_fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
        perror("bind");
        exit(EXIT_FAILURE);
    }

    if (listen(listen_fd, 128) == -1) {
        perror("listen");
        exit(EXIT_FAILURE);
    }

    set_nonblocking(listen_fd);

    int epfd = epoll_create1(0);
    if (epfd == -1) {
        perror("epoll_create1");
        exit(EXIT_FAILURE);
    }

    struct epoll_event ev;
    ev.events = EPOLLIN | EPOLLET;
    ev.data.fd = listen_fd;
    epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev);

    struct epoll_event events[MAX_EVENTS];

    printf("echo server started on port 8888\n");

    while (1) {
        int n = epoll_wait(epfd, events, MAX_EVENTS, -1);
        if (n == -1) {
            perror("epoll_wait");
            continue;
        }

        for (int i = 0; i < n; i++) {
            int fd = events[i].data.fd;

            if (fd == listen_fd) {
                // 新连接
                while (1) {
                    int conn_fd = accept(listen_fd, NULL, NULL);
                    if (conn_fd == -1) {
                        if (errno == EAGAIN || errno == EWOULDBLOCK) {
                            break;
                        }
                        perror("accept");
                        break;
                    }
                    set_nonblocking(conn_fd);
                    ev.events = EPOLLIN | EPOLLET;
                    ev.data.fd = conn_fd;
                    epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);
                    printf("new connection: %d\n", conn_fd);
                }
            } else {
                if (events[i].events & (EPOLLERR | EPOLLHUP)) {
                    close(fd);
                    continue;
                }

                if (events[i].events & EPOLLIN) {
                    char buf[BUFFER_SIZE];
                    while (1) {
                        ssize_t n_read = read(fd, buf, sizeof(buf));
                        if (n_read > 0) {
                            ssize_t n_write = write(fd, buf, n_read);
                            if (n_write == -1 && errno == EAGAIN) {
                                // 这里为演示简单，直接丢弃超出发送缓冲的数据
                                // 实际项目需要引入应用层发送队列
                                printf("send buffer full, drop data\n");
                            }
                        } else if (n_read == 0) {
                            printf("client %d closed\n", fd);
                            close(fd);
                            break;
                        } else {
                            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                                break;
                            }
                            close(fd);
                            break;
                        }
                    }
                }
            }
        }
    }

    close(epfd);
    close(listen_fd);
    return 0;
}

这个示例把 EPOLLOUT 的处理略掉了，因为 echo 场景下 send buffer 一般不会满。真实项目中，涉及向客户端下发大量数据时必须实现发送队列和 EPOLLOUT 机制，否则会在高并发下碰到数据丢失或写阻塞问题。

4. 调试与性能排查实战

4.1 高频问题排查方法

第一，绑定端口报错。服务器启动时报“bind: Address already in use”，通常是上一次的进程还没完全退出，或者端口处于 TIME_WAIT 状态。解决方法是程序里加 SO_REUSEADDR。如果是调试期间频繁重启，也可以手动 kill 旧进程，但根治方案还是设置这个选项。

第二，客户端连接已断开，但服务器一直不感知。TCP 是全双工协议，对端断电或异常退出时，本端可能不会立刻收到 FIN。短时间内不会有问题，但长连接场景下，一些死连接会一直占用 fd。解决方案有两个方向：启用 TCP keepalive（设置 SO_KEEPALIVE），或者应用层实现心跳机制，定期发送心跳包，收不到响应就主动断开。

第三，连接数上到一定规模后 epoll_wait 返回的 n 突然变得非常大。这通常是某个 fd 在 ET 模式下没有被正确处理，导致事件风暴。比如读数据循环没有在 EAGAIN 处退出，或者退出条件写错了，一直死循环 read。排查方法是加日志，打印每个 fd 的处理次数和时间，或者用 strace 跟踪系统调用。

第四，压测时发现内存持续增长。很可能是应用层发送队列里的数据不及时清空，对端读得慢，本端堆积的数据越来越多。解决方法是加流控，比如设置队列上限，超过阈值就断开连接或通知对端降低发送速率。

4.2 排查工具推荐

strace 是排查网络服务问题最犀利的工具。像这样用：

bash复制strace -f -e epoll_wait,accept,read,write,close -p 12345

可以实时看到某个进程的系统调用情况。比如 epoll_wait 频繁返回但 read 返回 0，说明连接被对端关闭但服务器没有及时处理。如果 accept 一直返回非阻塞错误，说明连接队列空了但事件没清干净。

netstat 和 ss 用于查看连接状态。比如看到大量 CLOSE_WAIT，说明对端关闭连接后，应用层没有正确调用 close。看到大量 TIME_WAIT，则多半是客户端的问题，跟服务器关系不大。

压测工具方面，简单场景可以用 nc 或者自己写并发脚本模拟。正式压测建议用 wrk 或者 JMeter，但 wrk 更多用于 HTTP，纯 TCP 压测可以考虑用自定义脚本。下面是一个简单的 Python 并发连接测试脚本：

python复制import socket
import threading

def test_conn(idx):
    try:
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect(("127.0.0.1", 8888))
        s.sendall(b"hello")
        data = s.recv(1024)
        s.close()
        print(f"conn {idx}: {data}")
    except Exception as e:
        print(f"conn {idx}: error {e}")

threads = []
for i in range(2000):
    t = threading.Thread(target=test_conn, args=(i,))
    t.start()
    threads.append(t)

for t in threads:
    t.join()

这个脚本注意不要一次性开太多线程，否则测试机的线程数也能成为瓶颈。实测 2000 个连接对 epoll 服务器来说是小意思，压力主要在网络和本机回环带宽上。

4.3 常见问题速查表

4.4 性能调优的三个实用方向

文件描述符上限是第一个要调的。Linux 默认单进程软限制通常是 1024，不调大它，epoll 监听数量再多也没用。临时调法：

bash复制ulimit -n 100000

永久调法要改 /etc/security/limits.conf，这里不展开。生产环境里我一般直接让服务进程内调用 setrlimit 来提升限制。

第二个方向是合理设置 epoll_wait 的 timeout 和 events 数组大小。events 数组太大会浪费内存，太小会导致单次事件处理不完，多几次 epoll_wait 调用。我一般取 1024 或 4096，根据实际并发量调整。

第三个方向是使用 EPOLLONESHOT 配合多线程处理。单线程 epoll 处理 CPU 密集任务时会卡住其他连接。把每个 fd 的事件设为 EPOLLONESHOT，触发后线程池里的线程负责处理这个 fd 的读写，处理完再重新注册。这种模型兼顾了 epoll 的高并发事件分发能力和多线程的并行处理能力，是目前生产环境最主流的组合方式。

5. epoll本身之外：并发服务器还需要什么

epoll 只解决了“怎么高效通知事件”的问题，一个完整的 TCP 并发服务器还需要考虑协议设计、编解码、定时器、连接管理这些额外的工程问题。

一个最简单的业务场景：客户端发送一段 JSON，服务器解析后写入数据库。这时候 epoll 循环里就不能只读数据，还要做 JSON 解析和数据库操作。如果这些操作耗时较长，单线程 epoll 模型会把所有连接都卡住。解决方案一般是：用 epoll 负责 I/O 事件调度，把耗时的业务处理丢给线程池或队列。

我最早写 epoll 服务器时，把所有逻辑都塞在事件处理里。结果压测一跑，某个请求处理慢了几百毫秒，整个服务的吞吐都塌了。后来改成“epoll + 线程池”的模型，epoll 只负责收发数据和解析分包，业务逻辑交给工作线程，问题才解决。

还有一种常见做法是“多 reactor”模式。多个线程各自运行一个 epoll 实例，主线程只负责 accept，把新连接轮流分配到各个 worker 线程的 epoll 实例上。这种模型能充分利用多核 CPU，适用于吞吐量极高的场景。Redis 虽然用的不是纯 epoll，但其事件循环思想正是这种模型的一个经典变体。

很多网络服务把 epoll 当作“事件驱动”的基石，但真正的架构难点在 epoll 之外：连接状态的维护、读半包和粘包问题、应用层发送缓冲、定时器管理（比如心跳超时）。epoll 把最底层“哪个 fd 有事件”这件事做得足够高效，上层就需要你设计得足够清晰。读数据时如果发现缓冲区里有一个不完整的报文，不能直接丢弃，也不能当成两个报文处理，这种情况必须做协议分包，而分包逻辑和数据积累，都是在应用层完成的。

我常用的一个模式是，每个连接用一个结构体来管理：

c复制struct conn_info {
    int fd;
    unsigned char *read_buf;
    size_t read_len;
    unsigned char *send_buf;
    size_t send_len;
    size_t send_cap;
    time_t last_active;
};

每个 fd 的 events 里的 data 指针指向这个结构体。这样在事件处理时直接拿到连接的完整状态，而不只是裸 fd。比如：

c复制struct conn_info *info = (struct conn_info *)events[i].data.ptr;

这个设计极大地方便了读半包和发送队列的管理。data 字段既能存 fd，也能存指针，官方推荐做法就是指向一块连接专用上下文。

6. 写在最后的一些心得

看到这里你应该对基于 epoll 的 TCP 并发服务器有了完整认识：模型怎么选、API 怎么用、代码怎么写、坑怎么填。

我个人强烈建议，初学者不要一上来就用 ET 模式和 EPOLLONESHOT，先用 LT 模式把 epoll_wait 的流程走通、把连接管理做好，再逐步往 ET 模式切换。LT 模式能容忍你一部分不严谨的代码，而 ET 模式对细节要求很高，任何一个事件没处理干净就可能导致连接卡死或数据丢失。

调试阶段有一个小技巧：在 epoll_wait 返回后，加一个计数器统计每次处理的事件数。如果这个数字经常超过 100，说明单次事件风暴已经很严重了，需要检查是否是某个 fd 的事件没有按预期清干净。正常业务场景下，每次 epoll_wait 返回十几个事件就已经不少了，几千个说明有问题。

关于压力测试，我再说一句。不要只看“能建立多少连接”，更要关注“客户端持续发送数据时，服务器的吞吐量和延迟是否稳定”。连接数只是表面指标，真正的考验是数据面在高并发下的稳定性。我见过不少服务连接数轻松过万，但一压数据就立刻现出原形。

最后一个建议：一定要学会读内核网络参数的语义。比如 /proc/sys/net/ipv4/tcp_tw_reuse 影响的是 TIME_WAIT 连接复用，/proc/sys/net/core/somaxconn 影响的是 accept 队列长度。epoll 只是事件通知框架，真正影响 TCP 传输行为的还有很多内核参数。遇到莫名其妙的网络现象，先用 netstat 和 ss 看清楚状态，再动参数，不要盲调。