现代 Nginx 已通过默认开启的 accept_mutex 机制基本消除 Accept 惊群效应：仅持有互斥锁的 worker 进程执行 accept()，其余等待或处理已有连接，避免内核唤醒全部进程空转。

在 Nginx 的多进程模型中，“Accept 惊群效应”（Thundering Herd）曾是早期版本的典型问题：当多个 worker 进程同时阻塞在 accept() 系统调用上，内核唤醒所有进程去竞争新连接，但最终只有一个能成功，其余空转消耗 CPU。现代 Nginx 已通过内置机制基本消除该问题，关键在于正确配置与理解其工作原理。

启用 accept_mutex 是核心防线

Nginx 默认开启 accept_mutex on（1.11.3+ 版本默认为 on），它让 worker 进程通过共享内存中的互斥锁协调 accept 权限：只有拿到锁的进程才进入 accept() 循环，其他进程继续处理已有连接或等待锁释放。这从根源上避免了内核级惊群。

• 无需手动修改源码或打补丁，确保配置中未显式关闭该选项（如 accept_mutex off）
• 若使用较老版本（accept_mutex on; 到 events 块中
• 该机制配合 multi_accept on; 可进一步提升单次获锁后的吞吐——即一次 accept 尽可能收多个就绪连接

依赖 SO_REUSEPORT（Linux 3.9+）可彻底绕过用户态锁

当内核支持 SO_REUSEPORT（Nginx 1.9.1+ 支持），且配置 listen 80 reuseport; 时，内核会在多个监听 socket（每个 worker 一个）间自动做负载均衡和连接分发。此时每个 worker 独立阻塞在自己的 socket 上，完全不触发 accept 惊群，也不依赖 Nginx 自己的互斥锁。

• 需确认系统内核 ≥ 3.9，且 Nginx 编译时未禁用 --with-http_v2_module 等影响 reuseport 的选项
• 启用后可通过 ss -tlnp | grep :80 观察多个进程监听同一端口（State 列显示 LISTEN 并带不同 PID）
• 注意：reuseport 对短连接更友好；长连接场景下，worker 负载可能因连接分布不均而略有倾斜，但远优于惊群

避免人为破坏机制的常见误操作

一些看似优化的配置反而会削弱或绕过上述保护，导致惊群重现或性能下降：

• 关闭 accept_mutex 同时又未启用 reuseport → 回退到原始惊群模式
• 设置 worker_processes auto; 但未限制最大值（如在 64 核机器上启 64 个 worker）→ 锁竞争加剧，上下文切换开销上升
• 使用第三方模块（如某些旧版 upstream 模块）覆盖事件循环逻辑，干扰 accept 流程
• 在容器或云环境中，宿主机未开启 net.ipv4.ip_unprivileged_port_start=0 等参数，导致 reuseport 绑定失败而静默降级

验证是否生效的简单方法

不依赖复杂压测，几个命令即可快速判断当前行为：

• 检查配置加载状态：nginx -t && nginx -V 2>&1 | grep -i reuseport 确认编译支持
• 观察监听状态：sudo ss -tlnp '( sport = :80 )' | grep nginx —— 若多个 PID 出现，说明 reuseport 生效；若仅一个 PID，则走 accept_mutex 路径
• 压力下看 CPU 分布：top -H -p $(pgrep nginx | tr '\n' ',' | sed 's/,$//')，若所有 worker 的 sy%（内核态时间）普遍偏高且波动同步，可能是锁争用或惊群残留