nginx 的 event loop 用单执行流通过内核事件通知（如 epoll）并发管理海量连接，避免线程创建、上下文切换与锁竞争；而传统阻塞模式为每个请求独占线程/进程，i/o 等待时执行流卡住，导致高并发下内存与 cpu 开销剧增。
Nginx 的 Event Loop 机制和传统阻塞模式是两种根本不同的 I/O 处理哲学，区别不在“快慢”，而在“资源调度逻辑”——前者用一个执行流管理海量连接，后者为每个请求独占执行流。
核心差异：执行模型完全不同
阻塞模式（如 Apache prefork）中，每个请求都绑定一个线程或进程：accept → read header → read body → process → write response，全程同步等待。只要某一步没完成（比如客户端发包极慢），该线程就卡住，无法做其他事。
Event Loop 模式（Nginx worker）中，所有连接共享同一个执行流：内核通知“这个 socket 有数据了”，就去处理它；“那个 socket 写缓冲区空了”，就继续发响应；处理完立刻回到循环开头，检查下一个就绪事件。没有“卡住”，只有“暂不处理”。
资源开销对比一目了然
- 内存占用：阻塞模型下，一个线程栈通常需 1–8 MB，1000 并发≈1–8 GB 内存；Nginx 单连接仅占 2–4 KB，1000 连接不到 4 MB
- CPU 切换成本：阻塞模型频繁线程切换（上下文保存/恢复），尤其高并发时调度器压力陡增；Event Loop 无切换，纯用户态循环 + 内核事件通知
- 系统调用频率：阻塞模型反复调用 read/write，常返回 EAGAIN/EWOULDBLOCK；Event Loop 用 epoll_wait 一次等待多个 fd 就绪，批量响应，调用次数大幅减少
行为表现差异很实际
遇到慢速客户端（如 Slowloris）：
- 阻塞服务器可能迅速耗尽线程池，新连接被拒绝，服务不可用
- Nginx 仍能维持数万空闲连接，靠 client_header_timeout 等超时参数主动断开异常连接，不影响其他请求处理
处理静态文件时：
- 阻塞模式：read() 从磁盘读完才 send()，期间线程闲置
- Event Loop：read() 返回 EAGAIN 后立即转去处理别的连接；磁盘 I/O 完成后由 aio 或线程池回调，或等内核 buffer 就绪再 send，全程不空等
不是“替代”，而是“适配不同场景”
Event Loop 不适合 CPU 密集型任务（如图像压缩、复杂模板渲染），因为单个请求长时间占用执行流会拖慢全局；阻塞模型反而更易横向扩展（多进程分摊计算）。但对 Web 服务最常见的场景——网络 I/O 密集、计算轻量（路由、转发、静态响应、TLS 握手）——Event Loop 的吞吐与延迟优势极为显著。
