3. 非阻塞IO原理

要真正理解 Node.js 为什么能用单线程扛住大量并发请求，必须把视线从 JavaScript 层下沉到操作系统内核。Node.js 的“非阻塞”并不是它自己发明的一种魔法，而是对操作系统提供的多路复用能力的一层封装。核心问题只有一个：一个线程如何同时“照看”成千上万个 IO 通道，并在其中任意一个就绪时立刻处理它。

文件描述符：一切 IO 的句柄

在类 Unix 系统中，无论是网络 socket、打开的文件、管道还是终端，内核都会返回一个非负整数——文件描述符（File Descriptor，fd）。它本质上是进程级“打开文件表”的索引，指向内核中的文件对象。Node.js 中每一个 TCP 连接、每一个被打开的日志文件，背后都对应一个 fd。

fd 的数量不是无限的。每个进程有软限制（ulimit -n，常见默认 1024）和硬限制。当 Node.js 作为高并发服务器时，fd 上限往往就是并发连接数的天花板。可以用下面的命令观察和调整：

# 查看当前进程的 fd 软限制
ulimit -n

# 临时提高到 65535（仅当前 shell 会话有效）
ulimit -n 65535

# 查看某进程实际打开的 fd 数量
ls /proc/<pid>/fd | wc -l

理解 fd 的意义在于：Node.js 的事件循环本质上就是在“轮询一批 fd，看哪些已经就绪”。而“怎么轮询”这件事，不同操作系统给出了完全不同的答案。

阻塞、非阻塞与多路复用

最朴素的 IO 是阻塞式的：调用 read() 后线程挂起，直到数据到达。一个线程只能服务一个连接，并发靠“一连接一线程”堆出来，线程切换和内存开销巨大。

非阻塞 IO 则让 read() 立即返回：有数据就返回数据，没数据就返回 EAGAIN。但若只是把阻塞改成非阻塞，程序就得不断循环重试（忙轮询），CPU 会被白白烧掉。真正的解法是IO 多路复用：把一批 fd 交给内核，由内核告诉你“哪些 fd 现在可读/可写”，线程只在有事件时才醒来工作。Node.js 的 libuv 正是构建在这一机制之上。

Node.js 非阻塞 IO 的底层链路 JS 调用 → libuv → 内核多路复用 → 事件回调 JavaScript 层 net / fs / dns 调用 libuv 事件循环 / 线程池 封装多路复用 API 内核多路复用 epoll / kqueue / IOCP 就绪事件通知 文件描述符 fd socket / file / pipe 三大平台多路复用机制对比 L epoll（Linux） 红黑树管理 fd + 就绪链表，O(1) 返回就绪事件 支持水平触发(LT)与边缘触发(ET)，无 fd 数量线性扫描 高并发首选，10 万连接仍保持低延迟 K kqueue（macOS / BSD） 统一事件队列，支持文件、socket、信号、定时器 内核直接返回事件数组，无需遍历全部 fd 性能与 epoll 同级，语义略有差异 W IOCP（Windows） 真正的异步 IO：提交请求后由内核完成并投递完成包 基于完成端口 + 线程池，模型与 epoll 本质不同 无“就绪”概念，只有“已完成”通知 libuv 屏蔽差异：同一套事件循环 API，底层自动选择 epoll / kqueue / IOCP

epoll 与 select/poll 的关键差异

早期的 select 和 poll 每次调用都要把整个 fd 集合从用户态拷贝到内核态，并由内核线性扫描所有 fd 判断就绪状态，复杂度是 O(n)。连接数一多，光是扫描就耗掉大量 CPU。

epoll 做了三件事来突破这个瓶颈：

  • 注册与等待分离：epoll_ctl 把 fd 一次性注册进内核的红黑树，之后 epoll_wait 不再重复传入整个集合。
  • 就绪链表：内核在 fd 就绪时通过回调把它挂到就绪链表，epoll_wait 直接返回链表内容，复杂度接近 O(1)。
  • 触发模式可选：水平触发（LT）只要缓冲区有数据就持续通知；边缘触发（ET）只在状态变化时通知一次，要求一次读干净，否则会丢事件。Node.js 在 Linux 上默认使用边缘触发配合非阻塞读循环。

IOCP 为什么是另一种范式

epoll 和 kqueue 属于“就绪通知”模型：内核告诉你“可以读了”，真正的读操作仍由应用线程发起。而 Windows 的 IOCP 是“完成通知”模型：应用把读请求连同缓冲区一起提交给内核，内核自己完成数据搬运，完成后把结果投递到完成端口。应用线程从完成端口取结果即可。

这意味着 IOCP 天然适合配合线程池，且不存在“就绪后还要再读一次”的往返。libuv 在 Windows 上正是用 IOCP 实现异步文件 IO 和网络 IO，因此 Windows 上文件 IO 是真正异步的；而在 Linux 上，普通文件 IO 无法用 epoll 高效处理（文件始终“就绪”），libuv 只能退回到线程池模拟异步。

关键结论：Node.js 的“非阻塞”在网络 IO 上由 epoll/kqueue/IOCP 直接支撑；但在文件 IO、DNS 查询（getaddrinfo）、加密计算等场景，底层依赖的是 libuv 的线程池（默认 4 个线程，可用 UV_THREADPOOL_SIZE 调整）。这也是为什么大量文件操作会互相排队。

对性能的实际影响

理解底层机制后，几个常见的性能现象就能解释清楚：

现象底层原因应对方向
连接数上万后延迟上升fd 软限制或 epoll 事件处理不及时提高 ulimit -n，减少单连接内存占用
大量文件读写变慢libuv 线程池默认仅 4 线程，任务排队调大 UV_THREADPOOL_SIZE，或改用流式处理
CPU 空转但吞吐不涨边缘触发下未读干净导致事件反复触发确保读循环直到 EAGAIN
Windows 与 Linux 行为不一致IOCP 完成模型 vs epoll 就绪模型避免依赖平台特定的 IO 时序假设

可以用一段最小示例观察事件循环与 fd 的关系：

const net = require('net');

const server = net.createServer((socket) => {
  // 每个连接对应一个 fd
  console.log('fd:', socket._handle.fd);
  socket.on('data', (d) => socket.write('echo:' + d));
});

server.listen(3000, () => {
  console.log('listening, pid =', process.pid);
});

启动后用 ls /proc/<pid>/fd | wc -l 观察，每建立一个连接，fd 数量就增加一个。当连接数逼近 ulimit -n 时，accept 会失败并抛出 EMFILE。这正是“文件描述符是并发上限”的直接证据。

调优提示：生产环境通常把 ulimit -n 设为 65535 或更高，并在 systemd 服务中通过 LimitNOFILE 固化；同时根据文件 IO 密集程度把 UV_THREADPOOL_SIZE 调到 8～64 之间，但不要盲目调大，线程过多会加剧上下文切换。

把这一节串起来看：fd 是 IO 的句柄，非阻塞让单线程不被挂起，多路复用让单线程能同时照看海量 fd，而 epoll/kqueue/IOCP 是三种平台给出的不同实现。Node.js 通过 libuv 把这些差异封装成统一的事件循环，让开发者用回调或 Promise 就能写出高并发程序——但封装不等于消除差异，理解底层模型，才能在遇到 fd 耗尽、线程池排队、平台行为不一致时快速定位并解决。

← 上一章 📖 返回目录 下一章 →