Nginx自动选用最合适的I/O多路复用机制，编译时探测系统能力优先启用epoll，不支持则fallback到poll或select；运行时可配置干预，且epoll因O(1)复杂度和ET模式更适高并发。
Nginx 并不“同时使用”select、poll、epoll 来实现兼容，而是根据运行环境**自动选用最合适的 I/O 多路复用机制**，并在编译和启动阶段完成适配。它的差异化兼容本质是：**编译时探测 + 运行时 fallback + 配置层可干预**。
编译时自动探测系统能力
Nginx 源码在 configure 阶段会检测目标系统的内核版本与可用的系统调用：
- 若 Linux 内核 ≥ 2.6 且支持 epoll_create()，则默认启用 epoll（最高优先级）
- 若不支持 epoll 但支持 poll()（如较老的 Linux 或部分 Unix），则 fallback 到 poll
- 若 poll 也不可用（极少见，如某些嵌入式或 BSD 变种），才退到 select
这个过程由 auto/os/linux、auto/event 中的脚本完成，生成的 Makefile 会链接对应模块（如 ngx_event_epoll_module.o），其他未启用的模块不会参与构建。
运行时按需加载与降级逻辑
Nginx 启动时，会读取配置中 events { use [epoll|poll|select]; } 的显式声明（若存在）；否则走自动选择路径：
- 即使配置写了
use epoll，但运行在不支持的系统上（如旧内核），Nginx 会打印警告并自动切换为 poll - 若配置了
use select，无论系统多新，都会强制使用 select（主要用于调试或极端兼容场景） - 所有模块都实现了统一的事件接口（如
ngx_event_actions_t函数表），上层代码无需感知底层差异
为什么 epoll 是默认首选？关键差异在行为层面
三者虽同属同步 I/O 多路复用，但底层机制决定性能边界：
- select：每次调用都要传入全部监听 fd 集合（位图），内核线性扫描；最大 fd 数硬限制（默认 1024）；需用户遍历整个集合查就绪项
- poll：用链表替代位图，无 fd 数量硬上限；但仍是轮询模式，时间复杂度 O(n)，高并发下效率仍低
-
epoll：内核维护红黑树存监听 fd，就绪事件通过回调入链表；
epoll_wait()直接返回就绪列表，时间复杂度 O(1)；支持边缘触发（ET）减少重复通知
对 Nginx 这类单 worker 进程处理数万连接的场景，epoll 的事件驱动模型避免了海量空轮询，显著降低 CPU 占用与延迟抖动。
实际部署中如何确认和干预
可通过以下方式验证当前生效的机制：
- 启动时查看日志：
nginx -t或nginx -V 2>&1 | grep -o "epoll\|poll\|select" - 运行中检查：
lsof -p $(cat /var/run/nginx.pid) | grep epoll（有 epoll 结果即启用） - 在 nginx.conf 的 events 块中显式指定（仅建议用于测试或受限环境）：
events {
use epoll;
worker_connections 10240;
}
