Nginx采用单线程事件驱动状态机模型，每个Worker通过epoll轮询处理数万连接的I/O阶段；Apache则用“每请求一线程”，线程全程独占资源并阻塞等待，导致高并发下内存与上下文切换开销巨大。
核心区别在于：Nginx 不为每个请求分配独立线程，而是让单个线程（Worker 进程）通过状态机驱动，轮询处理成千上万个连接的各个 I/O 阶段；而传统服务器如 Apache 的“每请求一线程”，是让每个请求独占一个线程，从头到尾同步阻塞执行，直到响应完成。
非阻塞 I/O 状态机：一次调度，多阶段推进
Nginx 每个 Worker 进程内部是一个事件循环，它不“等”任何事。当一个 HTTP 请求到达时，整个处理被拆解为多个明确状态：接收请求头、读取请求体、查找静态文件、转发给上游、写响应等。每个状态只做少量工作（比如从 socket 读几 KB 数据），若数据未就绪（如磁盘还没返回文件），就立刻保存当前上下文，转去处理其他连接的就绪事件。等内核通知“该连接可读/可写了”，再恢复对应状态继续推进。
这就像流水线工人：他不守着某件产品干完全部工序，而是每人只负责拧螺丝、贴标签、打包中的某一环，产品在工位间流动，人始终有活干。
关键点：
- 单线程可同时管理数万连接，内存开销极小（每个连接仅需几 KB 上下文）
- 无线程创建/销毁、无上下文切换成本
- 依赖 epoll/kqueue 等内核机制，只在真正就绪时回调，避免空轮询
“每请求一线程”：资源绑定，全程独占
Apache 的 prefork 或 worker 模式中，一旦建立 TCP 连接，就立即 fork 子进程或启用线程，该进程/线程会一直占用 CPU 和内存，直到整个请求生命周期结束——哪怕中间要等 200ms 从磁盘读一个 CSS 文件，它也原地挂起（阻塞），不能服务别人。
这就导致两个硬瓶颈：
- 并发连接数受限于系统能创建的进程/线程总数（如默认 256 个子进程）
- 高并发下，大量线程处于“睡眠等待 I/O”状态，CPU 花费大量时间在切换它们，而非真正干活
- 每个线程需独立栈空间（通常 1–8 MB），万级并发即消耗数十 GB 内存
状态机不是协程，也不靠操作系统调度
Nginx 的状态机完全由自身代码控制，没有使用用户态协程（如 Go 的 goroutine）或内核线程。它用纯 C 实现了有限状态自动机（FSM），每个请求在内存中只存当前状态码、缓冲区指针、待处理字节数等轻量字段。事件循环每次从 epoll_wait() 拿到一批就绪 socket，遍历它们，对每个调用对应的 handler（如 ngx_http_process_request_headers），handler 执行一小步后判断是否完成；未完成则注册下次可读/可写事件，返回循环头部。
这种设计使 Nginx 在低延迟、高吞吐场景（如静态文件服务、反向代理）中几乎榨干单核性能，而无需依赖语言运行时或复杂调度器。
本质差异一句话总结
传统模型是“人盯事”：一个线程绑定一个请求，死守到结束；Nginx 是“事找人”：所有请求排队等待就绪信号，哪个 ready 就处理哪一截，处理完立刻移交，绝不空等。
