Nginx的events块通过worker_connections、use、multi_accept和accept_mutex等指令调控I/O事件机制：worker_connections限制单进程连接数并影响epoll/poll/select效率；use显式指定epoll/kqueue/poll/select对应不同系统调用；multi_accept控制单次循环接受多个连接以降延迟；accept_mutex开启时用futex/eventfd避免惊群效应。
Nginx 的 events 块配置直接影响其如何与操作系统内核交互，尤其是 I/O 事件通知机制的选择和参数调优，这会显著改变底层系统调用的类型、频率和效率。
worker_connections 决定单进程最大并发连接数，影响 select/poll/epoll 的监控规模
该值设为 N 时，每个 worker 进程最多管理 N 个 socket 连接。在使用 epoll（Linux）或 kqueue（FreeBSD）时，Nginx 会一次性注册这 N 个 fd 到内核事件表；若用 poll，每次调用需遍历全部 N 个 fd；若用 select（已不推荐），则受限于 FD_SETSIZE（通常 1024），且每次调用都要拷贝整个 fd_set 到内核。
- 设置过大但实际连接数远低于该值，不会直接增加系统开销，但会占用更多内存（如 epoll 中 event 数组、连接结构体等）
- 设置超过系统 ulimit -n 限制会导致启动失败或运行时 accept 失败
- 建议值 ≤ 系统允许打开的最大文件数（
ulimit -n）并预留约 10% 给日志、临时文件等
use 指令显式指定事件驱动模型，对应不同系统调用族
Nginx 启动时根据 use 指令选择底层 I/O 多路复用接口，不同指令触发不同的系统调用：
-
use epoll;→ 调用epoll_create1()、epoll_ctl()、epoll_wait()（Linux 2.6.27+） -
use kqueue;→ 调用kqueue()、kevent()（FreeBSD/macOS） -
use poll;→ 调用poll()（跨平台，但 O(N) 时间复杂度） -
use select;→ 调用select()（已弃用，受 fd 数量和性能双重限制）
未显式配置时，Nginx 自动选择当前平台最优模型（如 Linux 默认选 epoll），但某些容器环境或旧内核可能需手动指定以规避自动探测失败。
multi_accept 控制单次事件循环中是否尽可能接受多个新连接
启用 multi_accept on; 后，Nginx 在一次 epoll_wait() 返回后，会循环调用 accept() 直至返回 EAGAIN，从而减少事件循环次数和系统调用开销。
- 开启后可降低延迟抖动，提升突发连接处理能力
- 但若连接到达速率极低，可能造成轻微 CPU 空转（反复 accept 失败）
- 依赖内核支持
SO_ACCEPTFILTER或TCP_DEFER_ACCEPT时效果更明显
accept_mutex 影响多 worker 下的连接争用行为，间接改变 futex 或 eventfd 使用模式
当 accept_mutex on;（默认），Nginx 使用共享内存 + 互斥锁（基于 futex 或 eventfd）协调多个 worker 对监听 socket 的 accept 权限，避免“惊群”（thundering herd）问题。
- 关闭后所有 worker 同时等待 accept 事件，内核唤醒全部，但仅一个能成功，其余线程无谓唤醒 → 浪费上下文切换和锁竞争
- 开启后仅一个 worker 持有 accept 锁，其他 worker 在锁释放前不尝试 accept，减少系统调用和调度开销
- 高并发下该选项对吞吐影响显著，尤其在连接建立频繁的场景（如短连接 API）
