Nginx的Non-blocking I/O通过事件驱动模型实现高并发，单worker可处理上万连接，避免线程切换与资源浪费，依赖epoll/kqueue精准调度，缓冲区按需分配复用，兼顾高吞吐与低延迟。
Nginx 的 Non-blocking I/O 不是让单次读写变快，而是从根本上改变连接管理方式，使有限资源能承载更多并发请求。
零线程切换开销
每个连接不独占线程或进程，worker 进程复用少量固定线程处理数万连接。系统无需为每个新连接分配栈空间、调度时间片，也避免了上下文频繁切换带来的 CPU 浪费。
- 对比 Apache prefork 模式：1 万个连接 ≈ 1 万个进程，内存和调度压力巨大
- Nginx 默认一个 worker 处理上万连接，仅靠事件循环驱动，资源占用稳定
事件驱动下的精准调度
它不轮询也不空等，而是依赖 epoll（Linux）或 kqueue（BSD/macOS）监听 socket 状态。只有当内核通知“可读”或“可写”，才真正调用 recv() 或 send()。
- 数据未就绪时，recv() 立即返回 EAGAIN，Nginx 就去处理其他就绪事件
- HTTP 头分片到达？继续监听该 socket，下一轮再读——整个过程不卡住主循环
- 慢客户端上传大文件？不影响其他连接的响应，资源不会被长期独占
缓冲区按需使用与复用
读写缓冲区不预先为每个连接分配大块内存，而是在事件回调中动态申请、及时释放，生命周期严格绑定连接状态。
- HTTP 请求头未收全？只扩容到 client_header_buffer_size 限制，超限则报错而非 OOM
- 大文件响应启用 sendfile？数据由内核直接从磁盘送入 socket，跳过用户态拷贝
- 连接关闭后，recv/send 缓冲区随 ngx_connection_t 结构体一并回收，无内存泄漏风险
高吞吐与低延迟兼顾
非阻塞 I/O 配合事件模型，让新请求或新数据能在毫秒级被捕获和调度，既提升单位时间请求数（QPS），又保障响应及时性。
- 短连接 API 场景：大量小包快速进出，CPU 几乎不空转等待
- 长连接 WebSocket 或流式响应：连接保持活跃，数据来即处理，不因个别延迟拖累整体
- 即使部分请求耗时较长（如后端代理等待），也不会阻塞同 worker 内其他连接的 I/O 调度
