为何Nginx按核心创建进程而非单进程多线程？

Nginx文档建议把worker_processes设为auto，实现每个CPU核心对应一个单线程的worker进程。虽然理论上进程上下文切换开销比线程高，但Nginx坚持这种架构有几个关键原因：

• 历史与兼容性优势：Nginx诞生于2004年，当时Linux的线程机制还不够成熟，不同Unix-like系统的线程实现差异很大。多进程模型在各类服务器系统上的兼容性更好，不需要为不同平台适配复杂的线程逻辑，能快速落地。
• 内存隔离提升稳定性：每个worker进程完全独立，某个进程因为bug或异常崩溃时，只会影响它正在处理的请求，其他进程仍能正常服务。如果是单进程多线程，一个线程崩溃可能直接拖垮整个进程，导致服务中断，风险高得多。
• 无锁设计避免性能损耗：多进程模型下，每个进程处理自己的连接队列，不需要用锁来共享资源（比如内存池、请求队列）。多线程架构则必须处理锁竞争问题，锁等待的开销往往比进程切换的开销更大，反而会拉低整体性能。
• 便捷的进程管理与热更新：Nginx的热重载、平滑升级依赖master进程对worker进程的信号管理——比如优雅关闭旧worker、启动新worker来加载新配置。单进程多线程的话，要在进程内协调线程的启停、资源交接，逻辑会复杂很多，很难做到这么平滑的更新。
• 实际场景下的切换开销可控：Nginx支持通过worker_cpu_affinity把worker进程绑定到指定CPU核心，每个进程固定在一个核心上运行，减少了跨核心上下文切换的概率。再加上Nginx用的是非阻塞IO模型，每个进程的事件循环效率极高，实际运行中进程切换的次数很少，开销几乎可以忽略。

内容的提问来源于stack exchange，提问作者Vishal