为何epoll_wait处理多个fd的性能优于处理单个fd？

为什么多FD场景下epoll_wait性能更好？ #

核心原因是系统调用开销的摊薄和内核批量处理的效率优势，具体拆解：

• 系统调用切换成本分摊：每次epoll_wait调用都会触发用户态到内核态的切换，这个切换有固定的开销（比如上下文保存、权限检查）。如果一次调用能取回100个就绪FD，相当于把这部分固定开销平摊到100个事件处理上；而单FD场景下，每个事件都要单独触发一次切换，总开销会成倍数上升。
• 内核事件处理的批量效率：epoll用红黑树管理所有监控的FD，当FD就绪时，内核会把它加入就绪链表。批量处理就绪事件时，内核不需要重复执行“遍历红黑树-标记就绪-加入链表”的全套流程，而是一次性处理多个就绪节点，减少了重复操作的冗余开销。
• CPU缓存 locality 提升：多FD就绪时，内核会把这些FD的事件信息批量拷贝到用户态的数组中，数据在内存中连续分布，能更好地利用CPU的L1/L2缓存；单FD场景下每次拷贝少量零散数据，缓存命中率低，间接拖慢了后续处理的速度。

多连接与单连接场景对延迟的影响 #

延迟的表现要分单次调用延迟和平均事件处理延迟来看：

• 单连接场景：
  • 单次epoll_wait的延迟更稳定，只要目标FD就绪就会立即返回，不会有额外等待。
  • 但如果连接的事件触发频率低（比如低频请求），epoll_wait会频繁陷入阻塞-唤醒循环，每次唤醒后的系统调用开销占比会很高，导致单个事件的整体处理延迟被放大。比如单次系统调用耗时0.1ms，而事件间隔是1ms，那系统调用开销就占了总延迟的10%。
• 多连接场景：
  • 平均事件处理延迟更低：因为系统调用的固定开销被分摊到多个事件上，每个事件的平均开销大幅降低。
  • 单次epoll_wait的耗时可能略有增加（比如大量FD同时就绪时，内核批量拷贝数据的时间变长），但这种增加远小于分摊后节省的总开销。
  • 注意：如果业务逻辑是串行处理就绪FD，后面的事件会因为前面的处理产生排队延迟，但这属于业务代码的问题，和epoll_wait本身无关。

误区澄清 #

不是监控的FD数量越多性能就越好——如果一万个FD里只有一个就绪，那epoll_wait的性能和单FD场景几乎无差异，甚至因为红黑树节点更多，内核查找就绪FD的时间会略长，但这点差异在实际场景中可以忽略。真正让性能提升的是一次epoll_wait调用能取回的就绪FD数量。

内容的提问来源于stack exchange，提问作者Tzvika Avni