根本原因不是线程性能差，而是nginx的任务模型天然不依赖线程并发：它用事件驱动（epoll/kqueue）替代“为等待而开线程”，以单线程+多进程实现高并发、低开销、强隔离与热更新友好。
Nginx 架构中不需要多线程，根本原因不是“线程性能差”，而是它的任务模型和资源调度逻辑天然不依赖线程并发——它用更轻量、更可控的机制完成了高并发目标。
事件驱动替代“为等待而开线程”
Web 服务绝大多数时间在等：等客户端发完数据、等磁盘读取文件、等后端响应返回。传统多线程为每个连接分配一个线程，结果大量线程卡在 I/O 等待上，白白占用内存（每线程默认 2–8MB 栈空间）和 CPU 切换开销（每次切换约 1–5μs）。Nginx 每个 worker 进程只用一个线程，靠 epoll/kqueue 让内核代为监听成千上万个连接的状态变化；有数据可读/可写时才触发处理，把“空等”这个动作完全交给操作系统，自身线程始终处于高效工作状态。
多进程已解决并行与隔离问题
Nginx 采用 master-worker 多进程模型，worker 数量通常设为 CPU 核心数。这带来三重实效：
- 天然利用多核：每个 worker 独占一个 CPU 核心，无锁竞争，无上下文切换干扰
- 故障自动隔离：某个 worker 因异常崩溃，master 可立即拉起新进程，其余 worker 继续服务，不影响整体可用性
- 内存与状态天然隔离：各 worker 使用独立内存池（如 ngx_pool_t），请求间不共享运行时状态，彻底规避线程安全问题和锁开销
业务逻辑本身不需线程级并发
Nginx 主要承担反向代理、静态资源服务、负载均衡等接入层职责，核心是快速转发、解析、改写 HTTP 流量，而非执行复杂计算或长事务。这类任务 I/O 密集、CPU 负载低，单线程事件循环足以吞吐数十万并发连接。若真遇到阻塞操作（如调用外部同步接口），最佳实践是交由上游服务异步化，或通过 OpenResty 的 Lua 协程做非阻塞封装，而不是在 Nginx 内部引入线程。
热更新与运维友好性依赖进程边界
配置热重载（nginx -s reload）和二进制热升级（USR2 信号）都依赖清晰的进程生命周期管理。master 控制旧 worker 优雅退出、新 worker 平滑接管，整个过程无服务中断。这种可控的进程启停模型在线程环境下难以实现——无法安全地“替换正在运行的线程集合”，也难以保证所有线程都完成当前请求再退出。
