nginx的master进程不参与运行时同步，仅负责初始化共享内存和锁结构、分发协作指令；worker进程通过继承的共享内存和预置互斥锁实现跨进程同步，master自身不读写共享数据。
Nginx 的 Master 进程本身不直接参与进程间同步操作，它不持有共享资源、不修改共享内存数据，也不参与锁竞争。真正的进程间同步发生在 Worker 进程之间，而 Master 的角色是创建同步基础设施并保障同步机制可用。
共享内存由 Master 统一分配并继承
Master 在启动初期调用 mmap() 配合 MAP_SHARED | MAP_ANONYMOUS 创建一块匿名共享内存区域，初始化为零。随后 fork 出所有 Worker 进程——由于 Linux 的写时复制（COW）机制，所有子进程自动继承同一块物理内存映射，地址空间中看到的起始地址（shm->addr）一致。这意味着：
- 无需额外 IPC 传递地址或句柄，Worker 启动即可见共享区
- 所有 Worker 对该内存的读写都作用于同一物理页（写操作触发 COW 仅限修改页，不影响其他进程读取原始内容）
- 像连接计数、限流令牌桶、缓存元数据等跨进程状态，天然具备“一份存储、多份视图”特性
同步原语由 Master 初始化，Worker 负责使用
共享内存本身不保证线程/进程安全，Nginx 在共享区内嵌入了同步结构（如 ngx_shmtx_t），其初始化由 Master 主导完成：
- Master 在
ngx_init_cycle()和ngx_event_module_init()阶段，为每个共享内存块（如limit_req、shared_dict）创建对应的互斥锁 - 锁的底层实现可选原子操作（自旋）、文件锁（
fcntl）或 POSIX 信号量，但对外统一抽象为非阻塞的ngx_shmtx_trylock() - Worker 进程在访问共享变量前，必须先尝试获取该锁；失败则短暂退避重试，不阻塞事件循环
Master 不参与运行时同步决策，但提供协调通道
当多个 Worker 需要协同行为（例如争抢新连接），Master 并不介入加锁逻辑，而是通过轻量级通信间接影响同步节奏：
- 启用
accept_mutex on时，Master 不直接加锁，而是通过 Unix 域套接字向 Worker 发送NGX_CMD_ACQUIRE_ACCEPT_LOCK指令，由 Worker 自行竞争全局 accept 锁 - 配置热重载期间，Master 启动新 Worker 并等待旧 Worker 自行退出（通过检查共享内存中的连接计数是否归零），不强制中断或加锁干预
- 日志写入由 Worker 将日志缓冲写入 pipe 或共享内存，Master 统一落盘——这本质是解耦 I/O，而非同步临界区
关键点总结
Master 对同步的贡献不是“执行同步”，而是：
- 一次性分配共享内存，让所有 Worker 共享同一物理页
- 预置锁结构并初始化，使 Worker 启动后即可安全调用
trylock - 通过指令式通信（channel socket）引导 Worker 协作节奏，避免盲等或冲突
- 自身完全规避对共享内存的读写，杜绝成为同步瓶颈或死锁源头
