企业官网建设流程全解析

写网络服务的人，大概率都干过这么一件事：用最朴素的方式写一个TCP服务器——accept一个连接，开一个线程去处理，再来一个，再开一个。一开始觉得没什么，等到连接数上来，线程数跟着爆炸，CPU开始打满，调度开销比业务逻辑还大。这时候你就需要认真对待一件事：I/O多路转接。

在整个Linux的高性能网络编程里，epoll几乎就是“高并发”的代名词。I/O多路转接这个词听起来很学术，但说白了就是让一个线程同时盯着成千上万个连接。而epoll正是在这个场景下最常用、最成熟、面试也最爱问的方案。这篇文章不打算讲太多空洞的概念，我直接把I/O多路转接的来龙去脉、epoll的内部机制、以及一个可用的epoll版本TCP服务器实现，一步步拆开给你看。内容偏向实战，也会穿插不少我踩过的坑，适合正在学Linux网络编程的开发者，也适合准备面试想把这部分彻底理清的朋友。

1. 先把问题摆清楚：为什么需要I/O多路转接

1.1 朴素模型的困境：从阻塞IO说起

很多人刚写网络程序时，代码大概是这样的：服务端调用accept阻塞在那，等客户端连上来，然后read阻塞着等客户端发数据。这个过程里如果只有一个连接，完全没问题，代码又短又清晰。但只要是两个以上的连接同时来，阻塞模型的短板立刻暴露——你在read第一个连接的socket时，第二个连接虽然在排队等accept，但根本没人理它，因为它还卡在第一个连接的读操作里。

为了让程序能“同时”处理多个连接，大家自然会想到多线程：每来一个连接就pthread_create开一个新线程，在线程里去阻塞读写。这种做法在连接数几十个的时候挺实用，代码改动也小。可一旦连接数到几千、几万，问题就严重了：线程本身要占栈空间，默认8MB左右，哪怕用线程池限制数量，上下文切换和锁竞争的开销也会把性能拖垮。更麻烦的是，绝大多数连接在一段时间内是空闲的——建立连接后，客户端半天不发数据，而线程只能阻塞在read上干等，资源被白白占着。

这就引出一个核心矛盾：网络IO的特点是“连接数多，但每个连接的数据量少、活跃时间短”。你真正需要关注的是那少数几个“准备好读或写”的连接，而不是把大量资源分配给所有空闲连接。能不能让一个线程去统一监视所有socket，哪个有数据来了就处理哪个，没事干的连接不占用资源？这就是I/O多路转接要解决的本质问题。

1.2 I/O多路转接解决的本质问题

I/O多路转接，英文叫I/O Multiplexing，它的核心是一个“监督者”的角色：替你盯着所有已连接的fd，告诉你哪些fd现在可读、哪些可写、哪些出了异常。你只需要在事件发生后再去调用对应的IO操作函数，就不会因为某个socket没数据而卡住整个进程。

这里有个非常容易误解的点：多路转接本身并不是“异步IO”，它依然是同步的。你在epoll_wait上阻塞等待事件，等内核告诉你“某个fd可读了”，你再自己去read。它跟信号驱动、AIO这类“内核帮你把数据搬好再通知你”的机制有本质区别。所以更准确的理解是：多路转接把“等”这件事集中起来了，把等待时间最大化复用，但真正的读写还是你自己来。

在Linux下实现多路转接有三个选型：select、poll、epoll。select和poll是早期提出的方案，机制简单，但都有明显的扩展瓶颈。epoll是Linux 2.6内核专门为解决大规模fd监视而设计的，它在设计思想和接口形式上跟select、poll完全不是一个量级。理解了epoll为什么快，你才算真正理解I/O多路转接。

2. 从select到epoll：到底改进了什么

2.1 select/poll的工作原理与瓶颈

很多人觉得select和epoll的区别只是“效率高低”，实际上它们的模型都不一样。

select的工作方式是把你要监视的fd放进三个集合（可读、可写、异常），每次调用select时，把这个集合从用户态拷贝到内核态，内核轮询一遍所有fd，把有事件发生的fd标记出来，再拷回用户态。你拿到结果后，还得再自己遍历一遍整个fd集合，去一个个检查“这个fd是不是可读了”。这里有两个明显的痛点：第一，每次调用都要全量拷贝fd集合，fd越多，拷贝开销越大；第二，内核和用户程序都要做O(n)的遍历，n是监视的fd总数，而不是就绪的fd数量。select还有一个硬限制：FD_SETSIZE默认是1024，也就说你最多监视1024个fd，想扩大还得重新编译内核或改动宏定义，非常不灵活。

poll针对fd数量限制做了解法，不再用固定大小的位图，改成pollfd数组，理论上fd数量可以很大。但poll的核心问题没解决——它还是要全量拷贝、全量遍历。连接数上来后，每次poll调用都要扫描那么多fd，而大多数fd根本没事件，这个浪费非常明显。

所以select和poll的共同本质是：每次调用都是“全量扫描、线性轮询”，内核只负责告诉你“有哪些fd已经就绪”，但这个“哪些”是通过把状态标记在你自己传入的fd数组里返回的，你还是要O(n)地再去扫一遍。当连接数达到几千，CPU时间几乎都消耗在“扫描无用fd”上了。

2.2 epoll的两个核心突破

epoll在设计上直接绕开了这两个痛点，核心思路可以总结为三点：

第一点是“只关心活跃fd”。epoll在内核里维护了一个事件表，你用epoll_ctl把需要监视的fd注册进去，内核只会在这些fd上发生你关心的事件时，把对应的fd放到一个就绪链表里。你调用epoll_wait时，拿到的基本就是“已经就绪的fd”，数量通常远小于全部fd。这样你就不用再一个接一个检查所有fd了，遍历成本O(k)，k是就绪数，而不是总连接数。

第二点是“减少数据拷贝”。select每次调用都要把fd集合从用户态拷到内核态，epoll通过epoll_ctl提前注册，内核和用户态共享同一份事件表，后续的epoll_wait不再需要重复拷贝全部fd信息，只是在就绪链表上取走结果而已。

第三点是“回调机制代替轮询”。select/poll的内核实现是遍历全部fd，检查状态。epoll则会给每个被监视的fd挂一个回调函数，当fd上发生事件（比如socket收到数据）时，内核自动调用回调，把这个fd放进就绪队列。这等于说，epoll的工作量只跟“有事件发生的fd”相关，跟“监视的fd总数”基本无关。

2.3 两种触发模式：LT和ET，理解它们是绕不开的坎

epoll有两种触发模式，理解它们的差异比背接口还重要。

水平触发（Level Triggered，LT）是默认模式：只要fd上有事件没处理完，每次epoll_wait都会提醒你。比如你一次性收到100字节，但只读了50字节，剩下的50字节还在接收缓冲区里，那下一次epoll_wait依然会把这个fd报告为可读。这种模式的好处是简单、不易漏事件，坏处是你可能被同一个事件反复叫醒多次。

边缘触发（Edge Triggered，ET）是“只在状态变化时通知”：只有当fd从“没有可读数据”变成“有可读数据”这个瞬间，你才会收到一次通知。内核不管你读没读完——如果通知后你没把数据读完，那在下一次新数据到来之前，内核不会再提醒你。所以ET模式下你必须一次性把数据读到读不出来为止（读到EAGAIN），否则就会丢数据。

用生活类比理解：LT就像快递员反复打电话提醒你“快递到了”，直到你取走为止；ET就像只通知你一次“有一批快递到了”，你自己必须一趟全搬完，不然就丢件。实际项目中，高并发服务往往用ET配合非阻塞IO，因为可以减少事件被重复触发的次数、降低系统调用量。但新手我建议先从LT入手，代码更稳，逻辑更直观，等搞清楚了再切ET。

3. 三个系统调用与关键参数，逐个弄明白

epoll的接口只有三个，刚上手时觉得少，反而容易忽略细节。这里的每个参数、每个返回值都值得抠清楚，因为它们直接决定了你后续的事件循环怎么写。

3.1 epoll_create：创建内核事件表

函数原型是：

#include <sys/epoll.h> int epoll_create(int size);

size参数在2.6.8内核以后其实已经不重要了，内核会动态调整事件表大小，当时设计这个参数的初衷是给内核一个“参考值”，让你告诉他大概要监视多少fd，但现在你传一个大于0的数就好。运行时一般直接写epoll_create(1)，写个几十、上百也完全没问题。

有个容易被忽略的点：epoll_create返回的是一个fd，它本身也占用一个文件描述符，程序结束时也要记得close，文件描述符泄漏多半就是这种不起眼的地方积累出来的。还有另一个系统调用epoll_create1，可以传EPOLL_CLOEXEC标志，配合多进程程序使用可以避免在exec执行其他程序时fd被意外继承，项目里我建议直接用epoll_create1。

3.2 epoll_ctl：注册、修改、删除事件

函数原型：

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

op有三类操作：EPOLL_CTL_ADD注册一个新的fd到事件表，EPOLL_CTL_MOD修改一个已经注册的fd的监听事件，EPOLL_CTL_DEL把一个fd从事件表里删除。event指向一个struct epoll_event，结构体定义如下：

struct epoll_event { uint32_t events; /* Epoll events，位图组合 */ epoll_data_t data; /* 用户数据，通常放fd或指针 */ };

events常用的位标志有这些：

• EPOLLIN：对应的事件是读事件，fd可读时触发。
• EPOLLOUT：写事件，fd可写时触发。
• EPOLLERR：fd发生错误，比如对端异常断开。
• EPOLLHUP：fd挂起，连接被挂断时触发，TCP对端发送RST或关闭连接时常见。
• EPOLLRDHUP：对端关闭连接或半关闭，这个比EPOLLHUP更精确，处理TCP连接关闭时很有用。
• EPOLLET：边缘触发模式，设置了这个位就表示该fd使用ET模式。
• EPOLLONESHOT：只触发一次，触发后该fd需要重新设置才能再次被监视，多线程模型里常用。

特别注意：EPOLLERR和EPOLLHUP不需要你显式注册，只要fd上出现这两种情况，内核总会把它们加到返回的就绪事件里。所以epoll_wait返回后，你不光要检查EPOLLIN、EPOLLOUT，还要检查这两种异常状态，否则连接异常断开时你可能毫无感知，资源也不会被清理。

3.3 epoll_wait：等待就绪事件

函数原型：

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

events是用户分配的一块内存，内核把就绪的事件拷贝到这里，maxevents必须大于0，告诉你这块内存最多能装多少个事件，通常和events数组的大小一致。timeout是超时时间，单位毫秒，为-1表示无限等待，0表示立即返回，大于0表示最多等待这么长时间。

返回值是本次就绪的事件数量。这个返回值非常重要，epoll_wait返回0表示超时，没有事件发生，返回-1表示出错。每次拿到就绪事件后，你要通过events[i].data.fd去找到对应的socket，再根据events[i].events去判断具体是什么事件。

3.4 关于event.data，一个容易被忽略的细节

epoll_event结构体里那个data字段，很多初学者只把它当“fd的存放处”，其实它是一个联合体。标准定义如下：

typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;

这里有个重要的设计思想：内核只负责帮你把这个data原样保存下来，当你调用epoll_wait拿到就绪事件时，这个data会跟着事件一起返回给你。它的好处是你不仅可以通过data.fd拿到fd，还可以用data.ptr挂一个你自己定义的结构体指针——比如一个封装了连接状态、接收缓冲区、发送缓冲区的上下文对象。

当你用EPOLL_CTL_MOD修改事件时，也可以用新的data把旧数据覆盖掉。我个人习惯是把连接对象指针放进data.ptr，而不是只存fd，因为事件循环处理时能直接拿到整个连接的上下文，省去一次“fd到对象”的映射查找。不过要注意指针的生命周期管理，连接释放后，如果epoll事件表里还残留着指向已释放内存的指针，那就是悬空指针，非常危险，后面我会讲怎么避免。

4. 一步一步实现基于epoll的TCP服务器

4.1 服务器框架设计

下面进入正题，我们来完整实现一个基于epoll的TCP服务器。为了让代码可复现，我采用LT模式加非阻塞socket的经典组合。为什么选择LT而不是ET作为起步？理由很简单：LT模式下即使某个fd没读完数据，内核下次还会继续通知你，逻辑上不容易丢事件，处理起来更宽容。等掌握了LT的完整流程，再切换到ET会顺手很多。

整个服务器的框架分为三层结构：

• 第一层是监听socket的创建和初始化：socket、bind、listen，设置非阻塞。
• 第二层是epoll实例的创建和监听socket的注册：epoll_create、epoll_ctl。
• 第三层是事件循环：epoll_wait返回后，根据事件类型分发处理，包括接受新连接、收发数据、处理异常断开。

我用C语言来写，因为Linux的epoll接口本身就是C接口，用C写最直接。工程上用C++封装的也不少，但底层逻辑完全一样。

4.2 socket、bind、listen的非阻塞改造

创建socket的代码大部分人都会写，但有一个关键细节必须注意：监听socket最好也设置为非阻塞。为什么？因为事件循环里，你调用accept时返回的只是“有连接进来了”的通知，但在高并发下，可能有多个连接同时到达，你一次accept只能取一个，剩下的还得继续接收。如果监听socket是阻塞模式，处理逻辑会复杂很多。

我们看这段完整的初始化代码：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/socket.h> #include <sys/epoll.h> #include <netinet/in.h> #include <arpa/inet.h> #include <fcntl.h> #define PORT 8888 #define MAX_EVENTS 1024 #define BUFFER_SIZE 4096 /* 设置非阻塞 */ static int set_nonblock(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 argc, char *argv[]) { int listen_fd, epoll_fd; struct sockaddr_in server_addr; /* 1. 创建监听socket */ listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd == -1) { perror("socket"); exit(EXIT_FAILURE); } /* 2. 设置地址可重用，避免TIME_WAIT导致bind失败 */ int reuse = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)); /* 3. 绑定地址和端口 */ memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(PORT); if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) == -1) { perror("bind"); close(listen_fd); exit(EXIT_FAILURE); } /* 4. 监听 */ if (listen(listen_fd, 128) == -1) { perror("listen"); close(listen_fd); exit(EXIT_FAILURE); } /* 5. 设置非阻塞 */ set_nonblock(listen_fd); /* 6. 创建epoll实例 */ epoll_fd = epoll_create1(0); if (epoll_fd == -1) { perror("epoll_create1"); close(listen_fd); exit(EXIT_FAILURE); } /* 7. 注册监听socket，关注读事件 */ struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev) == -1) { perror("epoll_ctl"); close(listen_fd); close(epoll_fd); exit(EXIT_FAILURE); } /* 8. 进入事件循环 */ ... }

这里有个经验：SO_REUSEADDR一定要设置。否则服务器进程刚退出、连接还处于TIME_WAIT状态时，你紧接着重启进程，bind可能会报Address already in use，排查时非常容易让人困惑。

4.3 事件循环的核心代码

事件循环是整个服务器的心脏，epoll_wait拿到的每个事件都要分类处理。这段逻辑我逐步解释：

struct epoll_event events[MAX_EVENTS]; struct sockaddr_in client_addr; socklen_t addr_len = sizeof(client_addr); while (1) { int n = epoll_wait(epoll_fd, events, MAX_EVENTS, -1); if (n == -1) { if (errno == EINTR) continue; /* 被信号中断，重试 */ perror("epoll_wait"); break; } for (int i = 0; i < n; i++) { /* 监听socket可读：有新连接 */ if (events[i].data.fd == listen_fd) { /* 这里用while循环，把当前所有的pending连接全部accept掉 */ while (1) { int conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &addr_len); if (conn_fd == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) break; /* 已经没有待处理的连接了 */ else if (errno == EINTR) continue; else break; } set_nonblock(conn_fd); struct epoll_event client_ev; client_ev.events = EPOLLIN | EPOLLRDHUP; client_ev.data.fd = conn_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, &client_ev) == -1) { perror("epoll_ctl(ADD)"); close(conn_fd); } } continue; } /* 处理异常事件：错误、挂断、对端关闭 */ if (events[i].events & (EPOLLHUP | EPOLLERR | EPOLLRDHUP)) { printf("connection %d closed or error\n", events[i].data.fd); close(events[i].data.fd); /* 实际工程里还要epoll_ctl DEL，见常见问题章节 */ continue; } /* 可读事件：接收数据 */ if (events[i].events & EPOLLIN) { char buffer[BUFFER_SIZE]; ssize_t recv_len; /* LT模式下，循环读直到读完为止 */ while (1) { recv_len = recv(events[i].data.fd, buffer, sizeof(buffer), 0); if (recv_len > 0) { /* 这里做业务处理，示例为回显 */ send(events[i].data.fd, buffer, recv_len, 0); } else if (recv_len == 0) { /* 对端关闭连接 */ printf("peer closed, fd=%d\n", events[i].data.fd); close(events[i].data.fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) break; /* 数据读完了 */ else { /* 真正的错误 */ close(events[i].data.fd); break; } } } } } } close(listen_fd); close(epoll_fd); return 0; }

epoll_wait采用timeout=-1无限等待，如果被信号打断返回-1且errno为EINTR，一定要continue而不是直接退出，这是很隐蔽的bug。监听socket的accept用while循环的目的是把内核里排队的连接全部取出来，因为EAGAIN才表示队列已经空了。如果是LT模式且用多线程处理，通常让一个线程专门accept，其余线程负责读写。

可读事件的接收，LT模式下也要用while循环，读一次可能没有把接收缓冲区读完，这里要一致读到返回EAGAIN，说明当前数据没有被读完的必要——不，准确说，读到EAGAIN表示内核缓冲区已经空了，该fd上的数据都读完了。LT模式你不读完，内核会一直通知你，导致事件循环空转。这点要记住。

4.4 LT与ET模式的改造差异

把上面这段代码改成ET模式其实改动不大，但每一处都有讲究。第一个改动是在设置客户端事件的events上加EPOLLET标志；第二个改动是accept和recv的循环逻辑必须足够彻底，ET模式下必须循环到EAGAIN为止——EAGAIN不再是“可选”的退出条件，而是必须的退出条件。否则你只处理了一次事件，剩下的数据就一直滞留在缓冲区里，直到新的数据到达才会触发新一轮EPOLLIN，这在业务上等于直接丢数据。

修改后的注册代码：

client_ev.events = EPOLLIN | EPOLLRDHUP | EPOLLET;

接收循环和上面一样，但要注意：如果缓冲区分多次recv，单次BUFFER_SIZE可能不够大，ET模式下你可以用一个更大的应用层缓冲区（比如16KB或申请大块内存）来暂存，或者采用“边读边处理”的策略。还有一个常见做法是在处理完EPOLLIN后，额外检查一次EPOLLOUT来把发送缓冲区清空，因为ET模式下写事件同样不会被重复触发。

修改后的完整代码流程其实和LT模式很接近，差异主要集中在“事件标志位”和“是否必须读到EAGAIN”上。这也是我希望你先在LT模式下把整个流程跑通的原因——切换ET时你只需要理解“为什么必须循环读到EAGAIN”，而不是同时要应付“accept处理、连接关闭、缓冲区管理”一堆新概念。

4.5 多线程下的延伸：EPOLLONESHOT的用法

单线程事件循环的瓶颈在于：每个连接的读、写、业务处理都在一个线程里串行执行。如果某个连接的recv拿到数据后，业务逻辑耗时较长（比如要查数据库），后面即使有几十个连接的数据就绪，也只能排队等它处理完。所以高性能服务通常把事件循环和业务处理分离：事件循环线程只负责收数据，然后把数据丢给工作线程，工作线程处理完再通过某种方式把响应交回给事件循环去send。

这种情况下，EPOLLONESHOT就非常有用了。它的语义是：事件触发一次后立即被内核从epoll的监视中移除（或者说是“禁用”），直到你再次EPOLL_CTL_MOD重新注册。这样能够保证：当一个工作线程正在处理某个连接的数据时，事件循环不会因为该连接又变可读而再次分发事件，避免了多线程同时操作同一个socket的竞态。

典型流程是：

1. 注册连接事件时加上EPOLLONESHOT。
2. epoll_wait返回后，把连接交给工作线程处理。
3. 工作线程处理完，再调用epoll_ctl(fd, EPOLL_CTL_MOD, ...)重新注册该连接的事件。

要注意的是，重新注册的时机要恰当：如果工作线程还没处理完，就重新注册了事件，新一轮的触发可能又把它丢给另一个工作线程，导致同一连接被两个线程同时读。你可以在重新注册之前确认处理确实结束，或者用锁保护。这一块是多个线程协作模型里的进阶话题，这里先做个提示，不展开写。

5. 实战中的常见问题与调试心得

5.1 LT和ET选错，业务逻辑直接乱套

很多人在自己的代码里同时混用了LT和ET，导致行为不可预测。例如监听socket用LT、客户端连接用ET，这时accept循环虽然一直在处理连接，但ET模式下的客户端数据如果没有一次读完，后续的EPOLLIN不再触发，数据就一直堆积。这种问题最难排查，因为它不是崩溃，而是“数据有时候能收到，有时候收不到”，复现也很随机。

我的建议是：在一个服务器进程内，明确每个fd使用哪种模式，最好统一。如果非要用不同的触发模式，至少把注册代码写清楚、注释明白，别靠记忆。这个坑我踩过一次，当时排查了一个下午，最后发现就是一个客户端fd被意外注册成ET模式引起的。

5.2 accept和recv没写循环，丢连接丢数据

在新手代码里，最常见的错误就是accept和recv只调用一次，而不考虑“有多个连接同时就绪”和“一次读不完一包数据”的情况。

accept只用一次的问题：如果多个连接同时到达，而你的accept只调用了一次，剩下的连接会一直留在内核的完成队列里。如果之后没有新连接来触发EPOLLIN，这些连接就永远没人处理，表现为“客户端connect成功了，但服务端一点反应都没有”。

recv只用一次的问题更隐蔽：你调用一次recv，拿到了当前缓冲区里的数据，但你不知道后面还有没有更多。LT模式下，内核会继续通知你，你的循环至少还能处理；ET模式下则直接丢失，数据就停在缓冲区里了。

正确做法就是我上面代码里展示的：accept用while循环，直到EAGAIN；recv在LT模式下读到EAGAIN为止，或者等到recv_len == 0处理关闭。

5.3 EPOLLOUT处理不当，CPU飙到100%

初学epoll时很多人会犯一个错：为了确保数据能及时发出，给所有连接都注册了EPOLLOUT。结果epoll_wait几乎每次都返回大量写事件，因为socket的发送缓冲区大部分时候都是空的——也就是说，fd“可写”是常态，不是稀有事件。你的事件循环就开始疯狂地“可写→无所事事→再次等待→又触发可写”，CPU直接打满。

正确的逻辑是：只有当你确实要向某个fd发送数据，但发送缓冲区可能已满（比如send返回EAGAIN）时，才临时注册EPOLLOUT，等可写事件触发后发送完成，立即移除EPOLLOUT。也就是说EPOLLOUT应该是“按需启停”的，而不是长期监视的状态。记住一句话：EPOLLIN是常态监视，EPOLLOUT是应急手段。

5.4 fd被关闭后的事件悬挂问题

这也是一个很典型的坑：你收到EPOLLHUP或EPOLLRDHUP事件，关闭了fd，但没有从epoll里删除它。然后在同一个epoll实例里，一个新的连接恰好分配到了这个fd值。epoll里的旧事件还在，它的data.fd和新的fd值相同，于是新连接的读写事件一起混进了旧连接的事件处理逻辑里，造成数据错乱甚至崩溃。

一个有效规避手段是：关闭fd之前，先调用epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL)把事件移除。这虽然不能百分之百防止fd重用带来的各种复杂问题（因为epoll_ctl和close之间可能还有竞态），但在单线程事件循环里这样做能大幅减少悬挂事件的可能性。

另一条更重要的守则：close(fd)后，绝对不要在事件循环里再引用这个fd，因为你无法准确知道它什么时候会被内核分配给别的连接。这一点在工程实践中极其重要。

5.5 一段调试经验：strace怎么用、日志怎么打

epoll程序调试起来比多线程还要绕，因为你面对的对象不是“线程栈”这种东西，而是一个看不见的内核事件表。我的调试三板斧如下：

第一，strace。strace -f -e epoll_ctl,epoll_wait,accept,recv,send ./server可以直接看到每次epoll_wait返回了什么事件、哪些fd触发了什么标识。有一次排查“某个连接为什么突然不触发任何事件”，就是用strace发现recv在阻塞模式下被第N次调用后卡住了——因为那个fd的EPOLLIN事件已经触发，但实际数据已经被其他处理逻辑读走，程序自己把自己搞死了。

第二，日志里打印events[i].events的十六进制值。这是个特别实用的小技巧，不要只打印"EPOLLIN"之类的字符串，因为事件经常是组合的，比如EPOLLIN|EPOLLRDHUP，你还要知道具体有没有EPOLLERR。打印原始值能帮你发现“咦，明明没注册EPOLLERR，它怎么出现了”这类hidden信息。

第三，给每个连接分配一个单调递增的连接ID，日志里统一用“fd+连接ID”来标记。这样排查问题时，你能清晰追踪“哪个连接在什么时候建立、什么时候关闭、数据从哪来”，否则一堆裸fd挤在日志里，根本没法看。

写在最后：我的一些实际体会

做网络编程这些年，我的一个很深的感受是：epoll并不难写，难的是理解它背后的“事件驱动”思维。很多人代码能跑，但问他为什么这里要循环accept，为什么ET模式下必须读到EAGAIN，为什么EPOLLOUT不能一直监听，答不上来。这些问题的答案都不在API文档里，而在你对Linux IO机制的理解里。建议你把上面这份代码自己敲一遍，然后故意制造一些异常情况——比如让客户端发完数据立即关闭、同时发起几百个连接、在收发之间人为加长业务处理时间——亲眼看看epoll在这些场景下的行为，比读十篇博文都管用。把LT吃透之后再切换到ET，你会发现自己对“事件驱动”这四个字的理解会上一个台阶。