Nginx通过accept_mutex实现互斥唤醒调度：仅一个worker抢锁成功后注册监听socket并处理accept，其余worker跳过，避免惊群；锁基于共享内存+原子操作，非内核阻塞。
nginx 通过 accept_mutex 机制规避多进程在 epoll_wait（或 select/kqueue）就绪后争抢 accept() 导致的“惊群”问题，但其本质不是传统意义上的“加锁”，而是一种基于共享内存 + 原子操作的**互斥唤醒调度策略**。源码层面的关键在于：不靠内核锁阻塞进程，而是让多数 worker 主动跳过 accept 阶段，仅一个 worker 尝试 accept 新连接。
accept_mutex 的开关与初始化逻辑（src/event/ngx_event.c）
该机制默认开启（accept_mutex = NGX_ENABLED），可通过配置 accept_mutex off; 关闭。启动时，nginx 在 master 进程 fork 前调用 ngx_event_process_init() 初始化事件模块，其中：
- 创建共享内存区
ngx_accept_mutex（类型为ngx_shmtx_t），用于跨 worker 同步； - 初始化
ngx_accept_mutex_held = 0（标志当前是否有 worker 持有 mutex）； - 设置
ngx_accept_disabled = 0（用于负载均衡调节，见下文）。
事件循环中如何决定是否尝试 accept（src/event/ngx_event_accept.c）
每个 worker 的事件循环（ngx_process_events_and_timers()）在进入 epoll_wait 前会执行 ngx_trylock_accept_mutex()。该函数核心逻辑是：
- 调用
ngx_shmtx_trylock(&ngx_accept_mutex)—— 底层使用atomic_cmp_set对共享内存中的锁变量做原子 CAS 操作； - 若抢锁成功：将
ngx_accept_mutex_held = 1，并把监听 socket 加入当前 worker 的事件队列（即rev->active = 1）； - 若抢锁失败：不注册 listen socket 事件，本次循环跳过
accept()； - 无论成败，都会调用
ngx_posted_accept_events处理已就绪的 accept 事件（若有）。
注意：抢锁失败的 worker 并不会阻塞，而是继续处理自己已有的连接事件（如 read/write），实现无锁调度。
accept 事件的实际处理与锁释放时机
只有持有 mutex 的 worker 才会在 epoll_wait 返回后收到监听 socket 的可读事件，并调用 ngx_event_accept()：
- 该函数循环调用
accept()直到返回EAGAIN（非阻塞 socket）； - 每 accept 一个新连接，会更新
ngx_stat_accepted和ngx_accept_disabled（当空闲连接数 ngx_accept_disabled = 1，降低本 worker 抢锁概率，实现简单负载均衡）； - 本轮 accept 结束后，立即调用
ngx_shmtx_unlock(&ngx_accept_mutex)（原子清零），释放 mutex，为下一轮竞争做准备。
为什么这不是“加锁阻塞”，而更像“轮叫+抢占”？
关键点在于：
- 没有进程因等待 accept 锁而挂起（无 sleep/wait）；
- 所有 worker 始终运行在自己的事件循环中，仅在是否注册 listen socket 事件上产生差异；
- 内核仍会向所有 worker 的 epoll 实例通知 listen socket 就绪（惊群仍发生），但只有持有 mutex 的 worker 真正响应；
- 从应用层看，效果等价于“每次只允许一个 worker accept”，但从实现看，是“每个 worker 自主判断是否参与 accept”。
这种设计兼顾了性能（无锁开销小、无上下文切换）、可预测性（避免多个进程同时 accept 导致负载不均）和兼容性（不依赖特定内核特性，Linux/FreeBSD/macOS 均可用）。
