Nginx 高效处理高并发的核心在于事件驱动架构：基于 epoll/kqueue 的非阻塞 I/O 配合单线程事件循环，使上下文切换从“每连接一次”降为“每事件一次”，大幅减少内核调度开销。
Nginx 之所以能高效处理大量并发连接，关键在于它没有依赖传统的“每连接一线程/进程”模型，而是基于非阻塞 I/O（如 epoll、kqueue）实现事件驱动架构，从而显著减少内核态上下文切换次数。
非阻塞调用如何减少上下文切换
在阻塞 I/O 模型中，当进程调用 read() 或 accept() 且无数据可读时，内核会将该进程置为睡眠状态，并触发一次上下文切换（保存当前进程寄存器、调度新进程）。连接数一多，频繁的等待与唤醒就会带来巨大开销。
而 Nginx 使用 epoll_wait()（Linux）等系统调用，以非阻塞方式批量监听成千上万个 socket 的就绪状态。它只在至少有一个 fd 就绪时才返回，期间进程始终运行在用户态，不主动让出 CPU，也无需反复进出内核——上下文切换仅发生在事件真正发生时，而非每个连接都触发一次。
事件循环 + 单线程（主工作流）是前提
非阻塞本身不自动降低切换开销，必须配合合理的执行模型：
- Nginx 主进程不处理请求，只做配置加载和 worker 管理
- 每个 worker 进程采用单线程事件循环，复用一个内核事件队列（如 epoll 实例）
- 所有 socket 都设为非阻塞模式（O_NONBLOCK），确保 read/write 立即返回，不会卡住事件循环
- 对慢操作（如磁盘读写、上游代理）也通过异步机制或子请求拆分，避免阻塞主线程
对比传统 Apache 的 fork/prefork 模型
Apache prefork 在高并发下为每个连接创建独立进程，每个进程都有自己的内存空间和内核栈。一旦并发连接达数千，不仅内存占用飙升，内核还需频繁在这些进程间调度，上下文切换呈线性增长。
Nginx worker 默认只启少数几个（通常等于 CPU 核心数），每个 worker 通过单线程+非阻塞+事件通知管理数万连接。内核只需维护少量进程上下文，调度压力大幅下降。
实际效果取决于正确配置与使用场景
非阻塞优势不是自动生效的：
- 需确认系统启用 epoll（Linux 2.6+ 默认）或 kqueue（BSD/macOS），而非低效的 select/poll
- worker_connections 值应结合 ulimit -n 调整，避免因文件描述符不足退化为阻塞行为
- 后端服务若响应缓慢（如未开启 keepalive 的 upstream），会导致 Nginx 长时间等待，间接增加 worker 占用，削弱非阻塞收益
本质上，Nginx 把“等待 I/O 完成”的责任从内核调度转移到用户态事件循环判断，把上下文切换从“按连接频次”压缩为“按事件频次”，这才是性能跃升的核心逻辑。
