Nginx非阻塞I/O核心在于“不等”：系统调用立即返回，无数据时返回EAGAIN/EWOULDBLOCK；配合epoll/kqueue事件机制，仅在socket就绪时处理，避免忙等待，单worker可高效管理数万连接。
核心就一句话：Nginx 不让 worker 进程“干等”，而是让它始终有事可做。
非阻塞调用：发起操作后立刻返回
传统阻塞 I/O（比如 Apache 的 prefork 模式）中，调用 recv() 读数据时，如果客户端还没发来数据，进程就会卡住、挂起，什么也干不了。Nginx 在 socket 上设置了 O_NONBLOCK 标志，意味着：
- 调用 recv() 或 send() 时，只要内核缓冲区没数据可读、或暂时无法写入，系统立刻返回错误码 EAGAIN 或 EWOULDBLOCK；
- 进程不会停住，而是马上继续执行后续逻辑，比如检查其他连接、处理定时器、响应已就绪的请求；
- 这就把“等待时间”转化成了“干活时间”，CPU 利用率更高，单个 worker 更“忙得过来”。
事件驱动配合：只在真正就绪时才动手
光靠非阻塞还不够——如果自己挨个轮询每个 socket 是否就绪，就是低效的“忙等待”。Nginx 的关键在于把非阻塞和操作系统级事件通知机制绑在一起：
- Linux 下用 epoll，FreeBSD/macOS 下用 kqueue；
- 这些机制允许 Nginx 一次性注册成千上万个 socket，并告诉内核：“有数据可读、可写、或出错了，请通知我”；
- 内核在背后监控所有 socket，一旦某个就绪，就主动把对应事件推送给 Nginx；
- Nginx 收到通知后，再对那个 socket 执行一次非阻塞的 recv()/send()，几乎总能成功，基本不白跑。
单 worker 管理海量连接的实质
一个 worker 进程能轻松支撑数万并发连接，不是靠魔法，而是这种组合带来的资源效率提升：
- 没有为每个连接创建线程/进程，内存开销极小；
- 几乎没有上下文切换（不用频繁切换不同连接的执行栈）；
- 所有连接共享同一个事件循环，调度由内核辅助完成，非常轻量；
- 连接越多，优势越明显——100 个连接和 10000 个连接，worker 的工作模式几乎一样。
对比阻塞模型：省下的不只是时间
阻塞模型下，一个连接卡住，就等于一个线程/进程被锁死；要撑住高并发，只能堆进程（Apache prefork）、堆线程（worker 模式），结果是：
- CPU 大量花在进程切换上，真正处理请求的时间变少；
- 内存随连接数线性增长，容易 OOM；
- 启动新进程本身就有延迟，影响吞吐和响应速度。
非阻塞 + 事件驱动跳出了这个陷阱，让有限的 worker 进程始终处于活跃状态，把硬件资源用在刀刃上。
