Nginx的Non-blocking IO不直接实现异步文件读取，而是通过事件驱动+sendfile零拷贝、AIO（需directio配合）、线程池三种策略协同规避阻塞：小文件用sendfile on高效传输，大文件启用aio threads或directio异步读取，确保worker不因磁盘I/O停顿。
Nginx 的 Non-blocking IO 本身并不直接实现“异步读取文件”，而是通过事件驱动 + 系统级非阻塞机制 + 多种 I/O 策略协同，间接达成高并发下的高效文件读取。关键在于：Nginx 不在用户态做真正的异步文件 I/O（如 Linux 的 io_uring 或 POSIX AIO），而是根据运行环境和配置，智能选择最合适的底层方式。
核心机制：事件循环与非阻塞 socket 是基础
Nginx 主进程+多 worker 进程模型中，每个 worker 使用单线程事件循环（epoll/kqueue/iocp）监听 socket 读写就绪事件。所有网络 I/O 都是 non-blocking 的——这意味着 accept、recv、send 调用不会挂起线程，返回 EAGAIN/EWOULDBLOCK 时立即继续处理其他任务。但这仅适用于网络套接字，不自动延伸到普通文件（如磁盘上的静态资源）。
普通文件读取为何不能直接 non-blocking？
Linux 中，常规文件（regular file）的 open() 默认就是 blocking 的，且 read() 对普通文件永远不会返回 EAGAIN —— 它总是同步等待磁盘 I/O 完成。所以 Nginx 若直接 read() 一个大文件，会阻塞整个 worker 进程，违背设计初衷。
为规避这点，Nginx 提供了以下几种应对策略：
-
sendfile() 零拷贝优化：当 serving 静态文件且启用了
sendfile on;，Nginx 将文件内容从磁盘直接由内核复制到 socket 发送缓冲区，全程不经过用户空间，也不调用 read()。这既避免了阻塞，又减少了内存拷贝，是默认推荐方式。 -
AIO（异步 I/O）支持（需显式启用）：在 Linux 上，配合
aio on;和directio（绕过页缓存），Nginx 可使用内核的异步 I/O 接口（基于 io_submit/io_getevents）。注意：该功能要求文件系统支持（如 ext4/xfs）、O_DIRECT 打开文件，并且只对大文件（> directio 阈值）启用，小文件仍走 sendfile 或普通 read。 -
线程池（thread pool）模式：启用
thread_pool default threads=4 max_queue=65536;并配合aio threads;，Nginx 将阻塞型 read() 任务提交给独立线程池执行，worker 继续处理事件循环。这种方式兼容性更好，无需 O_DIRECT，适用于无法启用 kernel AIO 的场景（如某些容器或旧内核）。
实际配置建议
要让 Nginx 在服务静态文件时真正“不阻塞”，应结合场景选择：
- 多数 Web 服务（如 HTML/CSS/JS）：启用
sendfile on;+tcp_nopush on;即可，高效且无额外开销。 - 大文件下载（如视频、安装包）：建议开启
aio threads;+thread_pool，并设置合理directio阈值（例如directio 4m;），使大块读取异步化。 - 若内核 ≥ 5.1 且业务对延迟极其敏感：可尝试
aio io_uring;（需编译时启用 --with-file-aio 和 --with-threads），利用 io_uring 实现更高效的异步文件 I/O。
为什么不是“纯异步”？
Nginx 坚持“一个 worker 一个 CPU 核心”的轻量模型，避免复杂回调或 Future/Promise 抽象。它用“事件驱动 + 条件切换 + 分离执行路径（如线程池）”的方式，把潜在阻塞点隔离或卸载，从而在宏观上表现出异步行为。这不是 Node.js 式的用户态异步 I/O，而是更贴近系统能力、更可控的工程折中。
