Nginx配置平滑加载依赖多进程模型与轻量锁机制，通过原子文件锁防并发reload、主从进程信号协作、fork内存隔离及连接分级退出实现不中断服务。
Nginx 实现配置平滑加载（即 nginx -s reload）依赖其多进程模型与一套轻量、高效的锁机制，核心不是靠传统互斥锁，而是通过 文件锁 + 进程信号协作 + 共享内存状态同步 完成的。它不阻塞工作进程处理请求，也不需要停服，关键在于主进程与工作进程之间“分阶段交接”的设计。
主进程用原子文件锁协调 reload 流程
当执行 nginx -s reload 时，信号（SIGHUP）发给主进程。主进程并不立即重读配置，而是先尝试以 O_CREAT | O_EXCL | O_RDWR 方式打开一个临时锁文件（如 nginx.pid.lock）。这个操作是原子的：成功即获得“reload 排他权”，失败说明已有其他 reload 正在进行，直接返回错误。
- 该锁仅用于防止并发 reload 冲突，生命周期极短，不涉及工作进程间同步
- 锁文件本身不存储状态，只起“占位”作用；释放时机是新 master 启动完成、旧 master 准备退出前
- 无需依赖系统级 fcntl 或 flock —— 基于文件系统原子性，跨平台兼容性好
新旧 master 进程通过信号+共享 pid 文件协同
获得锁后，主进程 fork 出新 master，并让其加载新配置、启动新 worker 进程；同时，旧 master 继续运行，其 worker 仍处理存量连接。两者通过 同一 pid 文件 和信号实现状态对齐：
- 新 master 启动 worker 后，向旧 master 发送
QUIT信号，通知其开始优雅退出 - 旧 master 收到后，不再 fork 新 worker，并向自己的 worker 发送
QUIT，等待连接自然关闭 - pid 文件始终只被新 master 持有并更新，确保外部工具（如 systemd）能准确识别当前主进程
worker 进程无锁读取配置，靠进程隔离规避竞争
Nginx 的 worker 进程是 fork 自 master 的，配置在 fork 时已完整复制进各自地址空间。reload 过程中：
- 新 worker 从新 master 继承的是新配置副本，旧 worker 仍运行在旧配置下，天然隔离
- 没有运行时动态修改配置变量的需求，因此无需在 worker 间加锁读取配置项
- 像 upstream 负载均衡状态、limit_conn 共享内存区等需跨 worker 协作的部分，才使用
ngx_shmtx_t（基于共享内存的自旋锁或文件锁后备），但这与 reload 流程本身解耦
真正起“平滑”作用的是连接处理的生命周期管理
锁机制保障了 reload 操作的串行化和原子性，但“不中断服务”的本质在于：
- 旧 worker 继续 accept 并处理已建立的连接，直到连接关闭或超时
- 新 worker 立即开始 accept 新连接，使用新配置（如新的 server 块、TLS 设置、proxy_pass 地址等）
- 监听套接字通过
SO_REUSEPORT（若启用）或主进程显式传递（默认方式）复用，避免端口冲突
整个 reload 的锁粒度极细，不阻塞网络 I/O，也不依赖复杂分布式协调。它把一致性问题拆解为：单机原子操作（文件锁）、父子进程协作（信号+pid）、内存隔离（fork 复制）、连接分级退出（graceful shutdown）—— 四者叠加，实现了高可靠、低开销的配置热更新。
