题干与适用场景
一个 Linux TCP 服务把监听 socket 和已连接 socket 都设为非阻塞，并用 epoll 驱动事件循环。客户端发送的数据已有 8 KiB 进入接收缓冲区。一次 epoll_wait 返回 EPOLLIN 后，处理函数只调用一次 recv，读走 4 KiB 就返回。
使用默认的水平触发（level-triggered，LT）时，服务下一次调用 epoll_wait 往往还能看到该连接。改成 EPOLLET 的边缘触发（edge-triggered，ET）后，同一实现偶尔不再收到可读通知，客户端一直等不到响应。请解释：
epoll的 interest list、ready list 和 I/O 就绪分别表示什么；- LT 与 ET 的通知契约为什么会产生不同结果；
- ET 下如何正确处理
accept、recv、send、EAGAIN、半关闭和错误； - 多线程 worker、
EPOLLONESHOT、热门连接公平性和 FD 复用会带来什么额外风险； - 如何通过可重复实验确认停滞原因并验证修复。
8 KiB 和 4 KiB 是面试场景数据，不代表 TCP 一次发送、一次系统调用或一个应用消息的固定大小。题目的核心是 Linux I/O 就绪契约，适用于后端、基础设施、SRE、系统软件和通用软件工程岗位，因此归为 general。
面试官考察点
第一，看候选人能否准确说出 epoll 报告的是“当前执行某类 I/O 是否可能不阻塞”的就绪状态，不是“一个完整请求已经到达”，也不是异步 I/O 的完成通知。TCP 是字节流，一次 recv 可以返回当前可用的任意正字节数。
第二，看是否真正理解 LT 与 ET。LT 会在关注的就绪条件仍成立时继续报告；ET 不承诺只因为条件仍然为真就重复通知。ET 收到事件后，应把 FD 视为可操作，直到非阻塞读写返回 EAGAIN 或 EWOULDBLOCK。只背“ET 只通知一次”过于绝对，也无法指导实现。
第三，看能否把同一原则正确应用到读、写和监听 socket。读侧要循环到 EAGAIN；监听侧要循环 accept4 到 EAGAIN；写侧不能永久关注通常一直可写的 EPOLLOUT，而应只在应用缓冲区还有未发送数据时关注它。
第四，看并发状态管理。EPOLLONESHOT 在一次通知后禁用该 FD，worker 完成状态更新后必须用 EPOLLCTLMOD 重新激活。重激活太早可能让两个 worker 同时操作一个连接，忘记重激活则表现为永久停滞。
第五，看候选人是否能处理“必须读到 EAGAIN”与事件循环公平性的张力。一个持续有数据的连接可能占用线程很久；若为公平性提前停止，应用必须把连接保留在自己的可运行队列，不能指望 ET 再给一个没有发生的新边缘。
回答前需要澄清的问题
- socket 是否真的非阻塞？ ET 配合阻塞 FD 时，第二次读写可能把负责许多连接的线程卡住。
- 停滞发生在监听、读取还是写回阶段？ 漏掉
accept、读剩余字节、EPOLLOUT更新或EPOLLONESHOT重激活，表象都可能是“连接卡住”。 - 应用协议如何判定完整消息？ TCP 没有消息边界；长度前缀、分隔符、HTTP 解析状态或连接关闭会决定何时可以处理请求。
- 处理函数一次读多少、何时返回？ 固定只读一次是本题最直接的缺陷；循环中做昂贵业务计算又会引出公平性问题。
- 连接是否跨线程处理？ 需要知道谁拥有读缓冲、写缓冲、关闭权和
epoll_ctl权限，是否启用了EPOLLONESHOT。 - 是否永久订阅
EPOLLOUT？ socket 大部分时间都可写，LT 下永久订阅会让epoll_wait立即反复返回，形成 CPU 忙循环。 - 如何处理
EPOLLRDHUP、EPOLLHUP和EPOLLERR？ HUP 到达时仍可能有数据未读，ERR/HUP 即使没有显式订阅也会报告。 - FD 是否可能被关闭后快速复用？ 仅把整数 FD 当连接身份，可能让延迟事件或异步任务误操作新连接。
30 秒回答框架
“epoll 维护关注列表并从就绪列表返回事件，它报告 I/O 就绪，不报告完整消息。LT 在条件仍就绪时会继续报告，所以只读 4 KiB 后剩余数据通常还会触发下一次等待；ET 不保证重复报告未变化的就绪状态，因此部分读取后可能一直等不到新通知。
ET 下所有相关 FD 都应非阻塞。监听 socket 要 accept4 到 EAGAIN，读要 recv 到 EAGAIN，写要 send 到 EAGAIN，并且只在写缓冲非空时订阅 EPOLLOUT。recv 返回 0 表示对端有序关闭写半边，其他错误要单独处理。多 worker 时可用 EPOLLONESHOT 保证单连接串行处理，完成状态更新后再 MOD 重激活。为防热门连接独占线程，可以设置处理预算，但提前停止时必须放入应用自己的就绪队列。最后用分段发送、部分读写、半关闭和并发压力复现，并检查每个连接最终到达 EAGAIN、正确重激活且无忙循环。”
分步骤深入解答
第一步：先建立 epoll 的就绪模型
epoll_create1 创建一个 epoll 实例，它本身由一个 FD 引用。概念上，实例包含两组状态：
- interest list： 应用通过
epollctl(EPOLLCTL_ADD/MOD/DEL)告诉内核要监控哪些 FD、哪些事件； - ready list： interest list 中当前有事件可用的项目，
epoll_wait从这里向应用返回结果。
“可读”表示一次读操作现在有机会取得数据、EOF 或错误而不必等待；“可写”表示当前至少可以推进一些写入，不表示整个响应一定能一次写完。应用仍要执行 recv、send、accept4 并检查返回值。事件是行动提示，系统调用结果才决定状态机下一步。
第二步：用未读完的 4 KiB 比较 LT 与 ET
默认 LT 的规则接近 poll：只要接收缓冲区仍有数据，读就绪条件仍成立，下一次 epoll_wait 可以再次返回这个 FD。因此错误的“每次事件只读一次”实现有时看起来能工作，只是制造额外唤醒和系统调用。
设置 EPOLLET 后，内核报告就绪状态发生变化的边缘。处理函数读走 4 KiB 后，缓冲区里还有 4 KiB，FD 仍处在可读状态；应用没有把它推进到“当前没有更多数据”的边界。ET 不承诺因为这个未变化的状态继续报告，所以等待新事件可能无限阻塞。
可靠规则是：收到 ET 事件后，把 FD 当作就绪，持续执行非阻塞 I/O，直到返回 EAGAIN 或 EWOULDBLOCK。这两个值表示“当前已无法继续，不会阻塞地完成更多操作”，应用此时才把通知权交回 epoll。
第三步：把读取实现为明确的状态机
下面是接近 C 的示意代码；协议解析、连接对象寿命和日志细节由应用补充：
void drain_read(Connection *conn) {
unsigned char buf[4096];
for (;;) {
ssize_t n = recv(conn->fd, buf, sizeof buf, 0);
if (n > 0) {
append_and_parse(conn, buf, (size_t)n);
continue;
}
if (n == 0) {
conn->peer_write_closed = true;
break;
}
if (errno == EINTR) {
continue;
}
if (errno == EAGAIN || errno == EWOULDBLOCK) {
break;
}
close_with_error(conn, errno);
return;
}
if (conn->peer_write_closed && output_is_empty(conn)) {
close_connection(conn);
}
}n > 0 只表示收到这些字节，解析器可能仍缺少完整请求；n == 0 表示对端对流式 socket 做了有序关闭，缓冲中的既有数据应先被消费；EINTR 可重试；EAGAIN/EWOULDBLOCK 是本轮排空完成；其他错误进入关闭路径。代码不能把“小于缓冲区长度”当作消息结束或已经读空的证明。
监听 socket 也遵循同样模式：收到可读通知后循环调用 accept4，为新连接原子设置 SOCKNONBLOCK | SOCKCLOEXEC，直到 EAGAIN。只接受一个连接就返回，会让已经排队的其他连接在 ET 下失去后续通知保证。
第四步：正确管理写缓冲和 EPOLLOUT
应用先尝试直接发送写缓冲。若 send 写入部分字节，就推进偏移并继续；若返回 EINTR 就重试；若返回 EAGAIN/EWOULDBLOCK，保留剩余数据并通过 EPOLLCTLMOD 加入 EPOLLOUT。下一次写就绪时继续排空。写缓冲清空后立即从关注掩码移除 EPOLLOUT。
永久订阅 EPOLLOUT 会造成另一个典型故障：socket 通常长时间可写，LT 会让等待持续立即返回，CPU 占用升高但业务没有进展。ET 也不能消除应用写缓冲、背压、最大缓冲量和慢客户端策略；它只改变通知方式。
第五步：处理半关闭、HUP、ERR 与关闭顺序
EPOLLRDHUP 表示流式 socket 的对端关闭连接或关闭写半边。EPOLLHUP 只说明对端已关闭通道；已有数据可能仍待读取，不能看到 HUP 就先丢掉缓冲。EPOLLERR 和 EPOLLHUP 无需在 interest mask 中显式设置，epollwait 仍会报告。错误路径可用 getsockopt(SOERROR) 取得待处理 socket 错误，再按协议记录并关闭。
关闭路径应先停止把新工作交给该连接，并确保异步任务不再持有过期身份。关闭指向底层 open file description 的最后一个 FD 会让内核移除对应注册；若描述被 dup 或 fork 共享，关闭其中一个 FD 不一定立刻消除相关事件，需要按所有权协议显式 DEL 或关闭全部引用。连接对象应使用受控寿命和 generation/token，避免整数 FD 被快速复用后让旧任务碰到新连接。
第六步：用 EPOLLONESHOT 管理 worker 并发
多个线程可以等待同一个 epoll 实例。对 ET FD，事件变为就绪时内核通常只唤醒一个等待者，但这不等于连接在整个处理期间天然只有一个 owner。事件分发到 worker 后，新的事件和应用队列仍可能造成并发状态访问。
EPOLLONESHOT 会在一次事件交付后禁用该 FD。worker 排空读写、更新协议状态和 interest mask 后，若连接仍存活，就调用 epollctl(EPOLLCTL_MOD) 重激活。重激活必须是交接的最后一步；忘记 MOD 会永久停滞，过早 MOD 可能让另一个 worker 在旧 owner 尚未结束时进入。
第七步：同时满足 ET 排空与公平性
“一直处理到 EAGAIN”在热门连接持续到流时可能占用线程，延迟其他连接。事件循环可以给每个连接设置字节、消息或时间预算。预算耗尽但尚未遇到 EAGAIN 时，不能简单返回并等待内核；应用必须把该连接加入自己的 ready queue，稍后继续处理，直到真正遇到 EAGAIN。
队列要防重复入队，并让连接关闭、worker 转移和 EPOLLONESHOT 重激活遵守同一个所有权协议。这样既保留 ET 的正确性，也避免一个热门 FD 饿死其他 FD。
第八步：设计能揭露漏边缘的验证
验证不能只跑一次正常请求。至少覆盖：
- 客户端一次写入 8 KiB，服务端故意每次最多读 4 KiB，确认修复前 ET 可停滞、修复后会继续读到
EAGAIN； - 客户端把一个应用消息拆成多次发送，并在任意边界暂停，确认解析不依赖单次
recv大小； - 限制服务端发送能力制造部分写和
EAGAIN，确认写缓冲不丢字节，清空后取消EPOLLOUT； - 测试对端半关闭、带未读数据的 HUP、连接重置和
EINTR； - 多 worker 下反复触发
EPOLLONESHOT，确认每次都有且只有一个 owner，并且存活连接都完成重激活； - 用一个持续发送的热门连接和许多低速连接检查公平性、CPU、事件循环延迟和 ready queue 长度；
- 高频建立与关闭连接，确认延迟任务不会因 FD 编号复用操作错误连接。
观测项应包含每轮 recv/send/accept4 的终止原因、EAGAIN 次数、interest mask 变更、oneshot rearm、应用 ready queue、单连接处理预算、事件循环延迟和无进展的连接数。通过条件是字节与协议状态正确、无永久停滞、无空转、无并发 owner，且低速连接不会被热门连接长期饿死。
高质量示范回答
“epoll 实例维护 interest list，并由 epoll_wait 返回 ready list 中的事件。它提供的是 I/O 就绪信息，不是完整 TCP 消息或异步完成通知。系统调用的返回值才是状态机依据。
本题在 LT 下看起来能继续，是因为读走 4 KiB 后接收缓冲区仍有 4 KiB，读就绪条件仍成立，下一次等待会继续报告。启用 EPOLLET 后，FD 没有回到不可读状态；ET 不保证为一个持续为真的条件反复通知，所以只读一次后重新等待可能永久卡住。
我会确保监听和连接 socket 都是非阻塞。监听事件循环 accept4 到 EAGAIN；连接读事件循环 recv 到 EAGAIN，把正字节交给增量协议解析器，0 视为对端关闭写半边，EINTR 重试，其他错误关闭。响应先直接 send，部分写就保留偏移；只有 EAGAIN 且还有待发数据时订阅 EPOLLOUT，清空后立即取消它。HUP 到达时先消费剩余数据，ERR 用 SO_ERROR 诊断。
多 worker 时我会给连接单 owner，并可使用 EPOLLONESHOT：worker 完成读写排空、状态更新和 mask 计算后再用 MOD 重激活。如果设置公平性预算却在 EAGAIN 前停止，我会把连接放入去重的应用 ready queue，不等待不存在的新边缘。连接身份使用带寿命或 generation 的对象，避免 FD 复用污染。
我会用 8 KiB 写入和 4 KiB 限读稳定复现，再加入部分写、半关闭、连接重置、oneshot、多 worker 和热门连接压力。修复后的证据是每个 ET 处理周期最终到达 EAGAIN 或明确关闭，待写数据完整发送，EPOLLOUT 不空转，所有存活 oneshot 连接都重激活，而且没有永久无进展或连接饥饿。”
常见错误
- 把就绪当成完整消息 → TCP 是字节流，单次
recv不对应应用消息 → 使用增量协议解析和独立输入缓冲。 - 把 ET 简化成“永远只通知一次” → 多个变化仍可能产生多个事件，关键是未变化的就绪条件没有重复通知保证 → 处理到
EAGAIN。 - ET 下只读一次 → 缓冲仍可读却没有新边缘 → 循环
recv到EAGAIN/EWOULDBLOCK。 - 阻塞 socket 配 ET → 排空循环可能阻塞并饿死整个事件循环 → 在注册前设为非阻塞。
- 监听 socket 每次只
accept一个连接 → 已排队连接可能没有后续通知 → 循环accept4到EAGAIN。 - 永久订阅
EPOLLOUT→ 通常可写的 socket 让等待持续返回 → 只在写缓冲非空时订阅，清空后移除。 - 看到 HUP 立即关闭 → HUP 时仍可能有未消费数据 → 先按读状态机排空，再根据 EOF 和输出状态关闭。
- 使用
EPOLLONESHOT后忘记重激活 → FD 已在 interest list 中禁用 → 状态更新完成后用EPOLLCTLMODrearm。 - 为公平性提前返回后等待新 ET 事件 → FD 可能一直保持就绪而没有新边缘 → 放入应用 ready queue 继续处理。
- 只用整数 FD 标识连接 → 关闭后的编号可能被新连接复用 → 使用有寿命控制和 generation 的连接身份。
- 宣称 ET 必然更快 → 实际结果取决于活跃比例、系统调用、业务处理和实现正确性 → 用真实负载比较 CPU、延迟、吞吐和公平性。
追问及应对
追问一：为什么 recv 返回小于缓冲区长度，仍不能说明已经读完？
recv 通常返回当时可用且不超过请求长度的字节数。网络分段、调度和发送时机都可能让它返回短读，后续字节仍会到达。ET 的排空边界是非阻塞调用返回 EAGAIN/EWOULDBLOCK；应用消息边界则由协议解析器决定，这两个边界也不相同。
追问二：ET 是否一定比 LT 性能更好？
不能只凭模式下结论。ET 可以减少一个持续就绪 FD 的重复通知，但会增加排空、用户态队列和状态管理复杂度。若大部分连接不活跃、业务处理成本更高或实现产生额外 epoll_ctl，收益可能很小。应在目标连接数和活跃分布下测 CPU、系统调用、吞吐、p99 和公平性，并把正确性放在首位。
追问三：为什么写缓冲清空后要取消 EPOLLOUT？
可写通常表示内核发送缓冲区还能接收一些字节，许多连接长时间满足这个条件。继续关注它会产生没有业务价值的通知，LT 下尤其容易忙循环。应用有待发送字节时才需要写通知；清空后移除，下一次业务产生响应时先直接尝试 send。
追问四：EPOLLONESHOT 与 ET 是同一件事吗？
不是。EPOLLET 改变就绪通知模式；EPOLLONESHOT 让 FD 在一次事件交付后被禁用，直到应用用 EPOLLCTLMOD 重激活。它们可以一起使用。ONESHOT 常用于 worker 所有权交接，但应用仍要正确排空 ET，并维护重激活协议。
追问五：预算耗尽时还没遇到 EAGAIN，怎样避免丢事件？
把连接标为用户态仍就绪，并放入去重 ready queue。调度器稍后继续 recv/send，直到 EAGAIN、关闭或再次耗尽预算。连接在用户态队列期间要保持有效 owner；若结合 ONESHOT，应在用户态工作完成并重新需要内核通知时才 rearm。
追问六：关闭 FD 后，为什么还要担心旧事件？
事件批次可能已经由 epoll_wait 交到用户态，异步 worker 也可能持有连接引用，而内核很快会把相同整数编号分配给新 socket。此外，多个 FD 可能引用同一个 open file description。关闭路径要先撤销新调度，管理连接对象寿命并使旧 token 失效；只比较整数 FD 不足以证明事件属于当前连接。