LibUV：Node.js 异步能力的底层支撑

LibUV 是一个用 C 语言编写的跨平台异步 I/O（输入/输出）库，它为 Node.js 提供了事件循环（Event Loop）、异步文件系统操作、线程池（Thread Pool）等核心能力。如果把 Node.js 比作一座工厂，V8 引擎是负责加工 JavaScript 代码的生产线，那么 LibUV 就是负责调度原料进出、管理运输管道的物流系统。没有它，工厂就只能等上一批原料全部处理完才能接收下一批。

LibUV 的设计目标很直接：让开发者在不同操作系统上都能使用同一套接口编写异步程序，而不必关心底层是 Linux 的 epoll（event poll，事件轮询）、macOS 的 kqueue（kernel queue，内核队列），还是 Windows 的 IOCP（I/O Completion Port，I/O 完成端口）。

事件循环的六个阶段

LibUV 的核心是它的 Event Loop（事件循环）。这个循环本质上是一个不断运转的调度器，每一轮（称为一个 tick，滴答/轮次）都会按固定顺序走过六个阶段，每个阶段维护着自己的 Callback（回调函数）队列。

timers（定时器）阶段：处理 setTimeout 和 setInterval 的回调
pending callbacks（挂起回调）阶段：执行上一轮循环中延迟的系统级 I/O 回调
idle / prepare（空闲/准备）阶段：LibUV 内部使用，业务代码一般不涉及
poll（轮询）阶段：检索新的 I/O 事件并执行对应的回调
check（检查）阶段：执行 setImmediate 的回调
close callbacks（关闭回调）阶段：处理 socket.on('close') 等关闭事件的回调

下面逐个说明这些阶段具体在做什么。

timers 阶段负责执行那些由 setTimeout 和 setInterval 注册的回调。LibUV 内部用一个最小堆来管理所有定时器，堆顶总是最近要到期的那个。进入这个阶段时，LibUV 会检查当前时间是否已经超过了某些定时器的设定阈值，如果超过了，就把对应的回调取出来执行。需要注意的是，定时器的延迟时间只是一个下限，不是精确的执行时刻。如果事件循环在之前的阶段被阻塞了，定时器回调就会相应推迟。

pending callbacks 阶段处理的是一些系统级操作遗留下来的回调。比如上一轮的 poll 阶段中，某些 TCP（Transmission Control Protocol，传输控制协议）连接出现了 ECONNREFUSED 这类错误，操作系统会把这些错误信息缓冲起来，LibUV 不会立刻在 poll 阶段处理它们，而是把它们推迟到下一轮循环的 pending callbacks 阶段执行。这样做是为了避免在 I/O 密集时让错误处理逻辑干扰正常的 I/O 回调流程。

idle 和 prepare 两个阶段完全由 LibUV 内部使用，比如 Node.js 的垃圾回收追踪、引擎状态锁定等操作会在这两个阶段完成。对于日常编写 JavaScript 代码的开发者来说，这两个阶段几乎没有直接参与的必要，知道它们存在即可。

poll 阶段是整个事件循环中工作量最大的阶段。它有两个任务：一是调用操作系统的事件通知机制（Linux 上是 epoll_wait，macOS 上是 kevent，Windows 上是 GetQueuedCompletionStatusEx）来检查有没有新的 I/O 事件到达；二是执行 poll 队列中所有已经就绪的 I/O 回调。如果 poll 队列为空，LibUV 会根据当前情况决定是阻塞等待新事件，还是直接进入下一阶段。具体来说，如果 timers 队列里还有未到期的定时器，LibUV 会计算一个阻塞超时时间，等到最近的定时器到期或者新事件到达为止；如果 timers 队列为空且没有活跃的 Handle（句柄），事件循环就会结束。

check 阶段专门留给 setImmediate。它的设计意图很明确：让某些回调在 poll 阶段结束后立刻执行，而不必等到下一轮循环的 timers 阶段。如果你在 poll 阶段的 I/O 回调里调用了 setImmediate，这个回调会在本轮循环的 check 阶段被执行，而不是像 setTimeout(..., 0) 那样可能被推迟到下一轮。

close callbacks 阶段处理资源关闭相关的回调。比如一个 socket 被突然销毁，或者一个文件描述符被关闭，对应的 close 事件会在这个阶段触发。如果资源是正常关闭的，这个事件也可能通过 process.nextTick 提前发出。

线程池与异步 I/O

LibUV 的事件循环运行在单线程上，但这并不意味着所有操作都在主线程完成。对于那些操作系统没有提供非阻塞接口的任务，比如文件系统读写、DNS（Domain Name System，域名系统）查询、加密计算等，LibUV 会把它们交给线程池（Thread Pool）处理。

线程池默认包含 4 个线程，这个数值可以通过 UV_THREADPOOL_SIZE 环境变量调整，上限是 1024。当主线程发起一个 fs.readFile 请求时，实际的磁盘读取操作会由一个后台线程执行，主线程继续处理其他事件。等到后台线程完成读取后，结果会通过回调机制通知事件循环，在合适的阶段把回调推入队列执行。

网络 I/O 的情况则不同。TCP、UDP（User Datagram Protocol，用户数据报协议）等网络操作通常可以直接使用操作系统提供的事件通知机制，不需要经过线程池。LibUV 会根据当前平台选择最优的实现：Linux 用 epoll，macOS 和 BSD 用 kqueue，Windows 用 IOCP。这种封装让 Node.js 的开发者可以用同一套 API 写出在所有平台上都能高效运行的网络程序。

uv_run 的三种模式

LibUV 提供了 uv_run 函数来驱动事件循环，它支持三种运行模式：

UV_RUN_DEFAULT：持续运行事件循环，直到没有活跃的 Handle 和请求为止。这是 Node.js 正常启动时使用的模式。
UV_RUN_ONCE：只执行一轮事件循环，处理完当前阶段的所有回调后返回，不管是否还有未处理的事件。
UV_RUN_NOWAIT：执行一轮事件循环，但如果 poll 阶段没有就绪的 I/O 事件，不会阻塞等待，而是直接返回。

这三种模式给了调用方灵活的控制权。比如 Node.js 的 REPL（Read-Eval-Print Loop，读取-求值-输出循环）交互环境可能会用 UV_RUN_ONCE 来逐轮处理用户输入，而长期运行的服务器进程则用 UV_RUN_DEFAULT 保持持续监听。

总结

LibUV 的价值在于它把操作系统层面的异步能力封装成了一致的接口。开发者不需要关心底层是 epoll 还是 IOCP，也不需要手动管理线程，只需要按照事件驱动的模式编写回调代码，LibUV 会负责把它们调度到正确的时机执行。

理解 LibUV 的事件循环阶段和线程池机制，有助于在排查 Node.js 程序的性能问题时找到方向。比如当发现定时器回调迟迟不执行时，可以检查是不是 poll 阶段被某个同步操作阻塞了；当文件 I/O 出现瓶颈时，可以考虑增大 UV_THREADPOOL_SIZE 的值。这些判断都建立在对 LibUV 工作机制的了解之上。