epoll_wait 不用每次传 fd 集合，select 每次都要全量拷贝；epoll 基于红黑树和就绪链表实现 O(k) 复杂度，select 为 O(n)，且 epoll 注册后零拷贝、无重复遍历。
epoll_wait 不用每次传 fd 集合，select 每次都要全量拷贝
select 每次调用 select()，都得把三个 fd_set（读、写、异常）从用户态完整拷贝进内核态；内核检查完，再把修改后的 fd_set 拷贝回用户态。下一次调用前你还得手动重置这些位图——这意味着重复拷贝 + 重复遍历。
epoll 则不同：epoll_ctl() 注册 fd 时只做一次拷贝，内核用红黑树存 fd，就绪事件走共享内存（mmap）或直接填入用户提供的 events 数组。后续 epoll_wait() 完全不传 fd 列表，零拷贝开销。
- 1000 个 fd 场景下，select 每次拷贝约 128 字节（
fd_set大小），epoll 仅注册时有拷贝，wait 阶段无数据传输 - 跨进程 fork 后，记得用
epoll_create1(EPOLL_CLOEXEC)，否则子进程可能意外继承并误触发
epoll_wait 返回的是就绪 fd 列表，select 必须线性扫描全部 fd
select 返回后，你必须遍历所有监听的 fd，逐个用 FD_ISSET() 判断是否就绪——哪怕只有 1 个 fd 活跃，也要扫完全部 1024（或你设的上限）。时间复杂度是 O(n)。
epoll 的就绪 fd 已由内核维护在链表（rdllist）中，epoll_wait() 直接返回实际就绪的那几个，应用层处理数量为 k，复杂度 O(k)，k ≪ n 是常态。
- 连接数 10 万、活跃连接仅几十时，select 扫描耗时占比飙升，epoll 几乎不变
- 别指望“连接少就选 select”——只要逻辑里写了
for (int i = 0; i ，就是隐式 O(n) 瓶颈
ET 模式 + 非阻塞 socket 是 epoll 高效的关键，但也是最易出错的地方
select 和 poll 只支持 LT（水平触发）：只要缓冲区有数据，下次 select() 还会通知你。这看似友好，实则掩盖了读不完的问题，也导致重复唤醒。
epoll 支持 ET（边缘触发），只在状态“从无到有”时通知一次。这要求你必须一次性读完（或写完），直到 read() 返回 EAGAIN 或 EWOULDBLOCK。否则数据滞留缓冲区，后续再无通知——静默丢包就发生了。
- 必须配合非阻塞 socket，否则一次
read()卡住，整个事件循环就停摆 - 正确写法是：
while (true) { n = read(fd, buf, len); if (n > 0) continue; else if (n == 0 || errno == EAGAIN) break; else error(); } - 漏掉
EPOLLET标志、或忘了设O_NONBLOCK，epoll 就退化成“更难调试的 select”
epoll 的扩展性来自内核数据结构，不是 API 表面简洁
很多人以为 “epoll 接口少所以好”，其实关键在内核实现：eventpoll 结构体里有红黑树（管理注册 fd）、就绪链表（rdllist）、回调函数（ep_poll_callback）。socket 状态变化时，内核直接调用回调把 fd 插入就绪链表——完全绕过遍历。
而 select 的 fd_set 是纯位图，内核只能挨个检查每个 bit 对应的 fd 是否就绪，没有索引、没有跳转、没有缓存局部性。
-
epoll_ctl(EPOLL_CTL_ADD)是 O(log n)，epoll_wait()是 O(1) 平均，select()每次都是 O(n) - FD_SETSIZE 不是硬限制而是设计缺陷：它让 select 天然不适合现代高并发场景
真正卡住性能的，往往不是“用了 epoll”，而是没对齐 ET + 非阻塞 + EAGAIN 循环这三者的协作节奏。一个 read() 漏掉 EAGAIN 判断，整条连接的数据流就断在内核缓冲区里了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
