nginx热加载不依赖锁，而是由master进程主导配置解析与分发，通过sighup信号触发、原子文件替换、fork新worker并优雅关停旧worker实现逻辑一致性，各worker独立持有只读配置副本，彻底规避并发冲突。

Nginx 在多进程模型中实现配置热加载（nginx -s reload）时，并不依赖传统意义上的“锁”来串行化配置加载过程，而是通过 master 进程主导 + 信号协作 + 文件原子性 + 进程优雅启停 的组合机制达成“逻辑上的一致性”，从而避免配置竞争和状态混乱。

master 进程是唯一配置解析与分发者

所有配置加载动作均由 master 进程完成：

• 收到 SIGHUP 信号后，master 进程重新读取、语法检查并解析 nginx.conf；
• 若解析失败，直接报错退出 reload 流程，worker 进程继续使用旧配置运行；
• 若成功，master 基于新配置 fork 出一批新 worker 进程，并向旧 worker 发送 QUIT 信号；
• 旧 worker 在处理完当前请求后自行退出，新 worker 接管连接——整个过程无共享内存或文件锁参与。

配置文件更新本身依赖原子性操作

为防止 worker 进程读到损坏或中间态配置，推荐做法是：

• 先将新配置写入临时文件（如 nginx.conf.new）；
• 再用 mv nginx.conf.new nginx.conf 原子替换（同一文件系统下为 rename 系统调用，不可中断）；
• master 进程 reload 时总是读取最新 inode 对应的内容，不会出现部分读取。

进程间无共享配置状态，避免锁需求

Nginx 各 worker 进程完全独立，不共享配置内存结构：

• 每个 worker 在启动时从 master 继承已解析好的配置结构体副本；
• 运行期间配置只读，无需运行时修改或同步；
• reload 不是“动态改配置”，而是“换一批新进程”，天然规避了并发读写冲突。

特殊场景下的显式同步（极少需要）

若在自定义模块中需跨进程共享可变状态（如限流计数、动态 upstream 列表），Nginx 提供有限同步原语：

• ngx_shmtx_t：基于文件或共享内存的轻量级互斥锁，用于保护共享内存段（如 limit_req 使用的 zone）；
• ngx_atomic_t：CPU 级原子操作，适用于计数器等简单变量；
• 注意：这些不是为“配置加载”设计，而是为运行时共享数据服务，且仅在启用 shared memory 指令（如 limit_req_zone）时才激活。

本质上，Nginx 的“平滑 reload”不是靠锁来保证安全，而是靠进程模型解耦 + 原子替换 + 单点控制来消除竞争根源。理解这一点，比纠结“用了什么锁”更能把握其设计本质。