Nginx通过accept_mutex锁机制避免惊群问题，仅允许一个Worker进程在满足条件时竞争accept操作，提升连接分发公平性与效率。
在 Nginx 中，Worker 进程通过 accept_mutex（Accept 锁）机制协调对监听套接字（listen socket）的 accept 操作，避免“惊群”（thundering herd）问题，同时提升连接分发的公平性与效率。
Accept 锁的作用与触发时机
多个 Worker 进程默认都处于 epoll_wait 等待状态，一旦有新连接到达，内核会唤醒所有监听该 socket 的进程。若不加控制，所有 Worker 都可能尝试 accept，造成资源竞争和低效——这就是“惊群”。Nginx 通过 accept_mutex 让同一时刻仅一个 Worker 尝试 accept，其余等待锁释放或下一轮事件循环。
该锁仅在以下条件满足时启用：
- 使用 epoll 或 kqueue 等支持边缘触发/就绪通知的事件模型（select/poll 不启用此锁）
- 配置项 accept_mutex on;（默认开启）
- 当前没有 pending 连接待处理（即未在 backlog 中积压）
Worker 抢占锁与连接获取流程
当一个 Worker 获得 accept_mutex 后，并非立即 accept，而是进入“抢连接”阶段：
- 检查监听 socket 是否就绪（epoll 返回 EPOLLIN）
- 循环调用 accept4()（Linux）或 accept()，直到返回 EAGAIN/EWOULDBLOCK
- 每次成功 accept 后，将新连接加入当前 Worker 的连接池，交由事件模块管理
- 释放 accept_mutex，允许其他 Worker 下次竞争
注意：一次持锁期间可能 accept 多个连接（尤其在高并发短连接场景），但不会无限阻塞——Nginx 设有 accept_mutex_delay（默认 500ms），防止某个 Worker 长期霸占锁。
影响 Accept 锁行为的关键配置
以下配置直接影响锁的争用策略和连接分发效果：
- accept_mutex on | off;：显式关闭可消除锁开销，但需确保系统能承受惊群（如使用 SO_REUSEPORT 内核特性时可关）
- accept_mutex_delay 500ms;：锁释放后延迟多久才允许下一次竞争，避免刚释放就被同一 Worker 抢回
- multi_accept on;：启用后，Worker 持锁期间会尽可能 accept 所有就绪连接（而非只 accept 一个），提升吞吐
- use epoll;：必须搭配 accept_mutex 才生效；若用 use reuseport;（需 Linux 3.9+），内核直接分发连接到不同 Worker，此时 accept_mutex 自动失效
常见误区与调优建议
实际部署中容易忽略几个关键点：
- 开启 multi_accept on; + accept_mutex on; 是高并发 HTTP 短连接场景的推荐组合
- 在容器或单核环境，Worker 数设为 1 可完全规避锁竞争，此时 accept_mutex 无意义
- 若观察到 accept() 失败率升高（如 accept() returned -1 (24: Too many open files)），优先检查 ulimit 和 connection leak，而非盲目调锁参数
- 使用 SO_REUSEPORT 时，应关闭 accept_mutex 并配合 worker_processes auto;，让内核完成负载均衡
