accept_mutex在现代linux（≥3.9）与nginx（≥1.9.1）中非强制开启：启用reuseport时自动失效，内核直接分发连接；未启用时仍为默认防线，防止epoll惊群，仅对epoll/kqueue有效。
在现代 Linux 内核（≥3.9）和较新 Nginx（≥1.9.1）环境下，accept_mutex 不再是“必须开启”的硬性配置，而是一个需要结合 reuseport 是否启用、负载特征与内核能力综合判断的取舍项。
reuseport 启用时，accept_mutex 自动失效
当配置中存在 listen 80 reuseport;，且系统满足以下条件：
- 内核版本 ≥ 3.9（支持 SO_REUSEPORT）
- Nginx 编译未禁用
--with-http_v2_module等影响 reuseport 的选项 - 监听端口未被非特权限制（如容器中需设置
net.ipv4.ip_unprivileged_port_start=0）
此时内核会在每个 worker 进程创建独立的监听 socket，并由内核直接做连接分发。Nginx 检测到 reuseport 生效后，会自动忽略 accept_mutex 配置——无论你写 on 还是 off，它都不起作用。
未启用 reuseport 时，accept_mutex 仍是默认防线
若因兼容性或环境限制无法使用 reuseport（例如旧版内核、某些云平台网络策略），则 accept_mutex on 是防止 epoll 惊群的关键机制：
- 它仅对 epoll/kqueue 有效；select/poll 下该指令无效
- Nginx 1.11.3+ 默认开启，无需显式配置；老版本（如 1.4.x）需手动加
accept_mutex on; - 搭配
multi_accept on;可提升单次获锁后的吞吐，减少锁争用频率
不建议关闭 accept_mutex 的常见误判
有人认为“内核已解决 accept 惊群，所以可以关掉”，这是对问题边界的混淆：
- Linux 2.6+ 确实优化了
accept()系统调用本身的唤醒逻辑（WQ_FLAG_EXCLUSIVE），但那是针对**直接阻塞在 accept() 上的进程** - Nginx 实际使用的是 epoll_wait + accept 组合，惊群发生在 epoll 层——多个 worker 的 epoll 实例同时监听同一 listen_fd，事件就绪时仍可能批量唤醒
- 关闭
accept_mutex又未启用reuseport，将退回到原始惊群模式：所有 worker 频繁被唤醒、尝试 accept、失败返回 EAGAIN，徒增上下文切换开销
验证当前生效机制的快速方法
不用压测，几个命令即可确认：
-
ss -tlnp | grep :80：若看到多个 PID 同时监听同一端口（State=LISTEN），说明 reuseport 已生效；否则依赖 accept_mutex -
nginx -V 2>&1 | grep -i reuseport：确认编译时启用了 reuseport 支持 -
strace -p $(pgrep nginx | head -1) -e trace=accept,futex -s 32 2>&1 | grep -E "(accept|futex)"：若频繁出现futex(FUTEX_WAIT_PRIVATE调用，说明 accept_mutex 正在工作；若只有 accept 且无 futex 等待，则大概率走的是 reuseport 路径
