为什么 Nginx 采用多进程模型，而不是多线程模型？

Nginx 采用 “多进程（单线程） + 异步非阻塞事件驱动” 的模型（即 Master-Worker 架构），而不是多线程模型，这是出于对高并发、高可用性、高性能和低资源消耗的极致追求。

具体原因可以从以下几个核心维度来解析：

1. 极致的稳定性与隔离性（高可用）

多进程的优势（内存隔离）： 在 Linux 系统中，进程之间拥有独立的内存空间。如果 Nginx 的某一个 Worker 进程因为发生异常（例如遇到 Bug、第三方模块引发段错误 Segfault 等）而崩溃，只会影响该进程内部正在处理的连接。Master 进程会立刻察觉并迅速拉起一个新的 Worker 进程，其他 Worker 进程完全不受影响。
多线程的劣势（一挂全挂）： 多线程共享同一个进程的内存空间。如果其中一个线程发生内存越界或段错误，会导致整个进程崩溃，意味着这台服务器上所有的并发连接都会瞬间断开。对于一个经常被用作流量入口的负载均衡器/网关来说，这种脆弱性是不可接受的。

2. 无锁化设计，避免竞争开销

多进程（无锁）： Nginx 的 Worker 进程数通常设置为与 CPU 核心数相等，并通过 CPU 亲和性（CPU Affinity）将每个 Worker 绑定到固定的 CPU 核心上。每个 Worker 进程独立处理属于自己的连接，不需要与其他进程竞争共享资源（除了少数全局共享内存如限流、缓存区，但这部分使用了极高效的自旋锁）。这使得 Worker 进程在处理请求时几乎是“无锁”运行的。
多线程（频繁加锁）： 线程间共享内存，在处理并发请求、修改全局状态时，必须大量使用锁（Mutex、读写锁等）来保证线程安全。锁竞争不仅会导致严重的性能损耗，还会引发频繁的线程上下文切换（Context Switch），消耗大量 CPU 资源。

3. 完美契合“异步非阻塞 + I/O 多路复用”

不需要用线程来支撑并发： 传统的多线程 Web 服务器（如早期的 Apache）采用的是“一个连接对应一个线程/进程”的同步阻塞模型。当连接建立或等待 I/O 时，线程会被挂起。
事件驱动（epoll）： Nginx 基于底层的 I/O 多路复用技术（如 Linux 的 epoll，FreeBSD 的 kqueue）。一个 Worker 进程可以通过一个死循环（Event Loop）同时监听和处理数以万计的并发连接。由于它本身就不会因为网络 I/O 而阻塞，因此根本不需要开启多线程来提高并发能力。多开线程不仅毫无意义，反而会白白浪费内存（每个线程需要独立的栈空间）和 CPU 调度时间。

4. 热部署与平滑升级（运维友好）

Nginx 的多进程架构使其能够极其优雅地进行配置重载（nginx -s reload）和二进制文件热升级，且不中断任何现有连接：

Master 进程收到 Reload 信号后，会重新解析配置文件。
Master 启动新的 Worker 进程（使用新配置）。
Master 向旧的 Worker 进程发送信号，旧 Worker 不再接收新连接，等处理完当前手头的请求后，自行优雅退出。
如果是多线程模型，要在不中断现有连接的情况下，安全地在运行时替换共享内存中的配置结构、销毁并重建线程池，在工程实现上极其复杂且容易出错。

5. 最大化利用 CPU 缓存（Cache Locality）

正如前面提到的，Nginx 鼓励将 Worker 进程绑定到特定的 CPU 核心（worker_cpu_affinity）。因为 Worker 是单线程循环处理事件，没有线程切换，这就保证了极高的 CPU 缓存命中率（L1/L2 Cache）。如果是多线程模型，线程会在不同的 CPU 核心之间来回调度，导致 CPU 缓存频繁失效，降低执行效率。

💡 补充：Nginx 真的完全不用线程吗？

严格来说，Nginx 并不是绝对的“零线程”。

Nginx 核心的网络请求处理坚决采用单线程多进程模型。但是，针对某些无法通过 epoll 实现异步非阻塞的操作（例如读取本地巨大的静态文件，磁盘 I/O 依然可能会阻塞进程），Nginx 在 1.7.11 版本引入了 Thread Pool（线程池） 机制。

工作机制： 当 Worker 进程遇到重度阻塞的磁盘 I/O 任务时，不会自己去死等，而是将这个任务丢给后台的“线程池”去处理，自己继续去处理其他的网络事件。线程池处理完后，再通知 Worker 进程。
结论： 这里的多线程仅仅是作为辅助工具，用于卸载偶尔的阻塞性 I/O 任务，Nginx 核心的事件调度和网络通信依然维持纯粹的多进程单线程模型。

播面