accept_mutex是防止惊群的协调机制，确保仅一个worker抢锁后执行accept()，其余跳过；它非负载均衡开关，需配合multi_accept和ngx_accept_disabled或reuseport才能实现连接均衡。
accept_mutex 不是用来“解决分配不均”的，它只负责避免惊群；真要让各 worker 连接数接近均衡，得靠 ngx_accept_disabled 自动调节 + reuseport 内核分发。
accept_mutex 实际作用是什么
它不是负载均衡开关，而是防止多个 worker 同时被唤醒去调用 accept() 的协调机制。Linux 内核在收到 SYN 包时，会把所有阻塞在 epoll_wait() 上的 worker 都唤醒——这就是惊群。accept_mutex 让只有一个 worker 抢到锁后才注册监听 socket 并执行 accept()，其余 worker 直接跳过，继续处理已有连接。
常见错误现象：
- 压测时
pidstat -w显示某几个 worker 的上下文切换（cswch/s）远高于其他进程（比如 5 倍以上） -
strace -p [pid] -e trace=accept,futex发现所有 worker 都频繁调用accept()并返回-1/EAGAIN
这通常说明 accept_mutex 没生效，可能原因包括：
- 用了
poll或select事件模型（该配置对它们无效） - 显式写了
accept_mutex off;且没启用reuseport - Nginx 版本低于 1.9.1 且未手动开启
accept_mutex on;
multi_accept 和 accept_mutex 必须配对使用
单独开 accept_mutex 只能保证“谁来 accept”，但如果不控制“一次 accept 多少”，就会导致锁轮转太勤、上下文切换白增。
multi_accept on; 的作用是：抢到锁的 worker 在单次事件循环中持续调用 accept()，直到返回 EAGAIN，把当前就绪队列里的新连接全收完。
性能影响明显：
- 短连接洪峰场景下，吞吐可提升 20%~40%
- 锁竞争频率下降，
pidstat -w中的cswch/s更平稳 - 必须搭配非阻塞 listen socket（Nginx 默认满足），否则可能阻塞后续读写事件
别写成这样：
events {
accept_mutex on;
# missing multi_accept —— 锁抢了又放，放了又抢
}reuseport 是 accept_mutex 的真正替代者
当你在 listen 指令里加了 reuseport，Nginx 就自动禁用 accept_mutex——因为内核已接管分发逻辑。
验证是否真正启用：
-
ss -tlnp | grep :80应看到多个PID同时监听同一端口（State 为LISTEN） -
nginx -V 2>&1 | grep -i reuseport确认编译时未禁用支持 - 检查内核：
uname -r≥3.9；容器环境还需确认net.ipv4.ip_unprivileged_port_start=0
注意兼容性陷阱：
-
reuseport对短连接更友好；长连接场景下，worker 连接数可能轻微不均（但远好于惊群） - 某些旧版第三方模块（如部分 upstream 控制模块）会干扰
ngx_trylock_accept_mutex()调用路径，导致静默失效 - 若
reuseport绑定失败（比如权限不足），Nginx 不报错，而是自动回退到accept_mutex模式
ngx_accept_disabled 才是隐式负载倾斜的关键
它不靠外部调度，而是每个 worker 自己算：“我快满了，先不抢锁”。计算公式是：(max_connections / 8) - available_connections。只要结果 > 0，该 worker 就跳过抢锁，把机会让给连接更少的兄弟。
这个值完全动态，无需人工干预，但它依赖两个前提：
-
worker_connections设置合理（不能远超物理内存和文件描述符限制） - 没人为关闭
accept_mutex（否则ngx_accept_disabled不触发）
容易被忽略的一点：这个机制只在 accept_mutex 生效的前提下起作用。如果你关了它又没开 reuseport，那 ngx_accept_disabled 就只是个摆设。
