Node.js 事件循环的六个阶段：深入理解 Poll 阶段与 Check 阶段的内核调用差异 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同仁，各位对Node.js异步编程充满热情的开发者们，下午好！

今天，我们将深入探讨Node.js的核心——事件循环。它不仅是Node.js实现非阻塞I/O的基石，更是我们编写高性能、可伸缩应用的关键。很多人对事件循环有一个模糊的认识，知道它有几个阶段，但对于各个阶段的内部运作机制，特别是Poll阶段与Check阶段之间的微妙差异及其内核调用层面的区别，往往一知半解。

因此，本次讲座的目标，便是带领大家剥开事件循环的层层外衣，直抵其核心，特别是聚焦于Poll和Check这两个经常被混淆的阶段，揭示它们在libuv层面的不同实现和与操作系统内核的交互方式。这将不仅仅是概念上的理解，更是深入到代码执行流程和系统调用层面的洞察。

让我们开始这场深度探索之旅。

Node.js 事件循环的宏观视图

首先，我们得对Node.js事件循环有一个整体的认识。Node.js采用单线程模型来执行JavaScript代码，但它通过事件循环和非阻塞I/O机制，实现了高并发处理能力。事件循环本质上是一个永不停歇的循环，它不断检查是否有待处理的事件，并将其对应的回调函数推入调用栈执行。

这个循环被libuv库实现，libuv是一个跨平台的异步I/O库，它抽象了不同操作系统的底层I/O机制（如Linux的epoll、macOS的kqueue、Windows的IOCP）。事件循环的每一次迭代，都称为一个“tick”或一个“cycle”，它会按照严格定义的顺序遍历一系列阶段。

经典的事件循环阶段通常被描述为六个：

Timers (定时器阶段)：处理setTimeout()和setInterval()设定的回调。
Pending Callbacks (待定回调阶段)：执行一些系统操作的回调，例如TCP错误。
Poll (轮询阶段)：这是事件循环的核心，负责处理大部分I/O事件的回调，并可能在此阶段阻塞等待新的I/O事件。
Check (检查阶段)：专门用于执行setImmediate()设定的回调。
Close Callbacks (关闭回调阶段)：执行所有close事件的回调，例如socket.on('close', ...)。

除了这五个主要阶段，我们还需要特别注意Microtask Queues (微任务队列)，它们在优先级上高于任何宏任务（即上述五个阶段的回调），并在事件循环的某些关键点被清空。

理解这些阶段的顺序和职责，是理解Node.js异步行为的基础。

微任务队列：优先级最高的插队者

在深入事件循环的宏观阶段之前，我们必须先厘清微任务（Microtasks）的概念。微任务队列并非事件循环的一个独立阶段，而是优先级更高的一组任务，它们在每个宏任务阶段之间以及特定宏任务阶段（如Poll阶段）结束后被清空。

Node.js中有两种主要的微任务：

process.nextTick()：这是Node.js特有的机制，其回调函数会在当前执行栈清空后立即执行，甚至在事件循环的任何阶段开始之前。它具有最高的优先级，可以理解为在当前JavaScript代码执行完毕后，但在浏览器渲染或下一个事件循环tick开始前，立即执行。
Promises (Promise.then(), Promise.catch(), Promise.finally(), await)：ES6引入的Promise对象的回调属于微任务。它们会在process.nextTick()队列清空之后，但在事件循环的下一个宏任务阶段开始之前执行。

让我们通过一个代码示例来观察它们的优先级：

console.log('Start');

setTimeout(() => {
    console.log('setTimeout callback');
}, 0); // 宏任务，进入 Timers 阶段

setImmediate(() => {
    console.log('setImmediate callback');
}); // 宏任务，进入 Check 阶段

Promise.resolve().then(() => {
    console.log('Promise.then callback');
}); // 微任务

process.nextTick(() => {
    console.log('process.nextTick callback');
}); // 微任务，优先级最高

console.log('End');

// 预期输出：
// Start
// End
// process.nextTick callback
// Promise.then callback
// setTimeout callback (或 setImmediate callback，取决于 Poll 阶段是否空闲)
// setImmediate callback (或 setTimeout callback)

在这个例子中，process.nextTick和Promise.then的回调会在主模块代码执行完毕（即End打印之后）后立即执行，且process.nextTick优先于Promise.then。然后，事件循环才会进入Timers阶段或Check阶段，执行setTimeout和setImmediate的回调。

微任务的存在，使得我们可以在当前操作完成后，立即执行一些清理或后续逻辑，而无需等待整个事件循环周期。这对于确保某些操作的原子性和顺序性至关重要。

事件循环的宏任务阶段详解

1. Timers (定时器阶段)

这个阶段负责执行那些满足条件的setTimeout()和setInterval()回调。当我们在代码中调用这些函数时，它们的回调会被放置在一个优先级队列中，等待事件循环到达这个阶段。

核心机制： libuv会检查当前时间是否已经超过了定时器设定的阈值。如果满足条件，相应的回调函数就会被推入任务队列，等待执行。值得注意的是，setTimeout(0)并不意味着它会立即执行，它仍然需要等待事件循环到达Timers阶段。

console.log('A');

setTimeout(() => {
    console.log('B - setTimeout');
}, 10);

setTimeout(() => {
    console.log('C - setTimeout with 0ms');
}, 0);

console.log('D');

// 预期输出：
// A
// D
// C - setTimeout with 0ms (如果 Poll 阶段没有 I/O 阻塞，且其他微任务已清空)
// B - setTimeout

在实际运行中，由于操作系统调度和其他因素，setTimeout(0)或setTimeout(1)并不保证精确执行。Node.js官方文档指出，即使是setTimeout(0)，其回调也可能在几毫秒后才执行，因为事件循环需要时间来处理其他任务并到达Timers阶段。

2. Pending Callbacks (待定回调阶段)

这个阶段通常不被我们直接接触。它主要用于执行一些系统级别的回调，例如在TCP连接中，如果前一个循环周期中发生了错误，相关的回调可能会在这个阶段被触发。

例如，一个net.Socket的error事件，如果是在上一个循环迭代中发生的，其回调可能会被延迟到这个阶段执行。这是一种内部的错误处理和资源管理机制。对于大多数应用开发者而言，这个阶段的直接影响较小，我们通常不会主动地将回调函数注册到这个阶段。

3. Poll (轮询阶段) – I/O 的核心

现在，我们来到了事件循环中最核心、也最容易产生困惑的阶段——Poll 阶段。这个阶段承担了Node.js非阻塞I/O的绝大部分工作。

主要职责：

处理I/O事件： 当操作系统通知libuv有I/O操作完成（例如，文件读取完毕、网络请求收到数据、数据库查询返回结果），libuv会将其对应的回调函数放入Poll队列，并在Poll阶段执行。
管理setImmediate的执行： 如果Poll队列为空（即没有待处理的I/O事件），并且存在已经安排的setImmediate回调，事件循环会跳过等待I/O事件，直接进入Check阶段来执行setImmediate回调。
阻塞等待： 如果Poll队列为空，并且没有待处理的setImmediate回调，事件循环可能会在这里阻塞，等待新的I/O事件发生。这是事件循环唯一可能长时间阻塞的阶段，因为它在等待外部事件。

内部机制与内核调用：

Poll阶段的核心在于libuv对底层操作系统I/O多路复用机制的封装和利用。在Linux上，这意味着libuv会使用epoll；在macOS上是kqueue；在Windows上是IOCP；而对于更老的系统或作为兼容性回退，可能会使用poll或select。

让我们以Linux的epoll为例来理解其内部调用过程：

注册文件描述符 (File Descriptors, FDs)： 当我们发起一个异步I/O操作（如fs.readFile()或net.createServer()），Node.js会通过libuv向操作系统注册相关的FDs。例如，一个网络socket或者一个文件句柄。libuv会调用epoll_ctl()来将这些FDs添加到epoll实例中，并指定我们感兴趣的事件类型（如可读、可写）。
等待事件： 当事件循环进入Poll阶段，并且Poll队列中没有现成的回调时，libuv会调用epoll_wait()（在其他系统上是kqueue()或GetQueuedCompletionStatus()等）。epoll_wait()是一个系统调用，它会阻塞当前的进程（或线程，对于libuv的I/O线程），直到：
- 有注册的FDs上发生了我们感兴趣的事件。
- 设定的超时时间到达。
- 被信号中断。
事件就绪与回调分发： 一旦epoll_wait()返回，它会提供一个列表，包含所有已经就绪的FDs及其事件。libuv会遍历这个列表，根据每个FD关联的Node.js回调函数，将其推送到Poll队列中。
执行回调： Node.js主线程随后会从Poll队列中取出这些回调并执行它们。

这个过程是阻塞在epoll_wait()这样的系统调用层面，而不是阻塞Node.js的JavaScript执行线程。当epoll_wait()阻塞时，Node.js的JavaScript线程处于空闲状态，等待I/O事件的完成通知。一旦通知到达，控制权回到JavaScript线程，执行相应的回调。

代码示例：

const fs = require('fs');
const net = require('net');

console.log('Start Poll Phase Demo');

// 模拟文件读取，这是一个典型的 I/O 操作
fs.readFile('./non_existent_file.txt', 'utf8', (err, data) => {
    if (err) {
        console.error('File read error:', err.message);
    } else {
        console.log('File read success:', data);
    }
});

// 模拟一个网络服务器，监听端口
const server = net.createServer((socket) => {
    socket.on('data', (data) => {
        console.log('Received data from client:', data.toString());
        socket.write('Hello from server!');
    });
    socket.on('end', () => {
        console.log('Client disconnected.');
    });
});

server.listen(3000, () => {
    console.log('Server listening on port 3000');
});

console.log('End Poll Phase Demo setup');

// 配合 setImmediate 观察 Poll 阶段的行为
setImmediate(() => {
    console.log('setImmediate callback 1');
});

setImmediate(() => {
    console.log('setImmediate callback 2');
});

// 如果 Poll 队列在某个时刻是空的，而 setImmediate 回调存在，
// 那么事件循环可能直接跳到 Check 阶段执行 setImmediate。
// 但如果 I/O 事件很快完成，那么 I/O 回调会在 setImmediate 之前执行。

在上面的例子中，fs.readFile的回调和net.createServer的on('data')、on('end')等回调都是在Poll阶段处理的。当文件读取完成或网络数据到达时，libuv会通知Node.js，并将相应的回调函数放入Poll队列。

4. Check (检查阶段) – `setImmediate` 的专属领地

Check阶段是事件循环中专门用于执行setImmediate()回调的阶段。它紧随Poll阶段之后。

主要职责：

执行setImmediate回调： 只要有通过setImmediate()注册的回调函数，它们就会在这个阶段被依次执行。

内部机制与内核调用：

与Poll阶段截然不同，Check阶段的实现更为简单和直接。它不涉及任何操作系统级别的I/O多路复用或等待机制。libuv为setImmediate维护了一个独立的内部队列（或者说，一组uv_check_t句柄）。

当事件循环到达Check阶段时，libuv会：

检查内部队列： libuv会遍历其内部维护的uv_check_t句柄列表，这些句柄代表了所有已注册的setImmediate回调。
执行回调： 对于每一个活动的uv_check_t句柄，libuv会调用其关联的JavaScript回调函数。

这个过程完全是在Node.js进程的用户空间中完成的，没有进行任何系统调用来等待外部事件。它仅仅是处理一个内存中的数据结构（队列）。因此，Check阶段的执行效率通常非常高，因为它不涉及昂贵的内核态/用户态切换和I/O等待。

代码示例：

console.log('Start Check Phase Demo');

setImmediate(() => {
    console.log('Immediate callback 1');
});

setImmediate(() => {
    console.log('Immediate callback 2');
});

setTimeout(() => {
    console.log('Timeout callback (0ms)');
}, 0);

console.log('End Check Phase Demo setup');

// 预期输出：
// Start Check Phase Demo
// End Check Phase Demo setup
// Immediate callback 1 (如果 Poll 阶段空闲，可能先于 setTimeout)
// Immediate callback 2
// Timeout callback (0ms) (或反之，取决于 Poll 阶段是否有 I/O 阻塞)

在I/O操作内部使用setImmediate是一个常见的模式，用于将任务推迟到下一个事件循环迭代，而不会阻塞当前的I/O回调。

const fs = require('fs');

fs.readFile('/path/to/some/file.txt', (err, data) => {
    if (err) throw err;
    console.log('File read complete.');

    setImmediate(() => {
        console.log('Processing data with setImmediate.');
        // 可以在这里进行一些CPU密集型但又不想阻塞 I/O 回调的后续处理
    });
});

console.log('After fs.readFile call');

在这个例子中，setImmediate的回调将会在文件读取回调执行完毕后，当前事件循环的Poll阶段完成后，进入Check阶段时被执行。这确保了文件读取回调本身能尽快完成，释放I/O资源。

5. Close Callbacks (关闭回调阶段)

这个阶段用于执行所有close事件的回调函数。例如，当一个socket或server被关闭时，它们的'close'事件监听器会在这个阶段被触发。

const net = require('net');

const server = net.createServer((socket) => {
    // ...
});

server.on('close', () => {
    console.log('Server closed!');
});

server.listen(0, () => { // 监听随机端口
    console.log('Server started on port:', server.address().port);
    server.close(); // 关闭服务器，其 'close' 事件回调将在 Close Callbacks 阶段执行
});

// 预期输出：
// Server started on port: <port_number>
// Server closed!

这个阶段通常在事件循环的末尾，处理资源的最终清理工作。

核心对比：Poll 阶段与 Check 阶段的内核调用差异

现在，我们聚焦于本次讲座的核心——Poll阶段与Check阶段在内部调用上的本质区别。

特性	Poll 阶段 (轮询阶段)	Check 阶段 (检查阶段)
主要目的	处理 I/O 事件的回调（文件、网络、数据库等），并可阻塞等待新的 I/O 事件。	专门执行 `setImmediate()` 注册的回调。
`libuv` 机制	依赖 `libuv` 的 I/O 多路复用后端（`uv_backend_fd`, `uv_io_poll`）。	依赖 `libuv` 内部维护的 `uv_check_t` 句柄队列。
与 OS 内核交互	直接与操作系统内核进行系统调用 (`epoll_wait`, `kqueue`, `GetQueuedCompletionStatus` 等) 来等待 I/O 事件完成。	不直接与操作系统内核进行系统调用来等待事件。纯粹的用户空间操作，处理内部队列。
阻塞行为	可能阻塞。如果 `Poll` 队列为空且没有待处理的 `setImmediate`，事件循环会在此阶段阻塞一段时间（由 `libuv` 内部逻辑决定，通常有一个超时），等待 I/O 事件。	不阻塞。一旦进入此阶段，它会快速遍历并执行所有 `setImmediate` 回调，然后立即进入下一阶段或下一个事件循环迭代。
回调来源	`fs.readFile()`, `net.createServer()`, `http.request()`, `database.query()` 等 I/O 操作的回调。	`setImmediate()` 注册的回调。
`setImmediate` 影响	如果 `Poll` 队列空闲，事件循环可能短路并立即进入 `Check` 阶段执行 `setImmediate`。	专门处理 `setImmediate` 回调，执行顺序与 `setTimeout(0)` 相比，在 I/O 回调内部有优势。
性能考量	涉及内核态/用户态切换，以及 I/O 等待，可能带来一定的延迟。但这是非阻塞 I/O 的本质。	纯用户空间操作，执行效率高，延迟极低。

深入解释内核调用差异：

Poll 阶段的内核调用：
libuv在Poll阶段的核心功能是调用操作系统提供的I/O多路复用API。这些API（如epoll_wait）是阻塞的系统调用。这意味着，当Node.js的事件循环发现Poll队列为空，且没有其他高优先级任务（如setImmediate）需要立即处理时，它会将控制权交给操作系统内核。内核会将Node.js进程（或更精确地说，libuv的I/O线程）置于等待状态，直到以下条件之一满足：
1. 某个已注册的文件描述符（如网络socket或文件句柄）上的I/O事件变为就绪状态（例如，数据可读，缓冲区可写）。
2. epoll_wait等系统调用设定的超时时间到达。
  当条件满足时，内核会唤醒Node.js进程，并将就绪事件的信息返回给libuv。libuv再根据这些信息，将相应的JavaScript回调函数推入Poll队列，等待Node.js主线程执行。
  这个过程是Node.js实现高并发非阻塞I/O的根本。它避免了为每个连接创建一个线程的资源开销，而是通过一个线程（事件循环）在内核的协助下高效地管理成千上万个并发连接。
Check 阶段的内部调用：
Check阶段则完全不同。它不进行任何阻塞式的系统调用。当事件循环进入Check阶段时，libuv仅仅是检查其内部的一个uv_check_t句柄列表。uv_check_t是一种libuv内部的“check handle”，用于管理setImmediate回调。
libuv会迭代这个列表，对于每一个已激活的uv_check_t句柄，它会调用其内部存储的Node.js回调函数。这个过程是纯粹的用户空间操作，没有I/O等待，没有内核态/用户态切换来等待外部事件。它就像一个简单的for循环，遍历一个数组并执行其中的函数。
因此，Check阶段的执行速度非常快，它旨在提供一种机制，允许开发者在当前事件循环迭代结束时，尽快执行一些非I/O相关的任务，而无需等待下一个Timers阶段。

为什么这种差异很重要？

理解这种差异对于编写高性能和可预测的Node.js应用程序至关重要：

setImmediate与setTimeout(0)的执行顺序：
- 在一个I/O回调内部，setImmediate总是先于setTimeout(0)执行。这是因为I/O回调在Poll阶段执行完毕后，事件循环会立即进入Check阶段处理setImmediate，而setTimeout(0)的回调则要等到下一个Timers阶段。
- 在主模块代码中，它们的执行顺序是不确定的，这取决于Poll阶段是否空闲。如果Poll阶段有I/O事件需要处理，setTimeout(0)可能会先执行；如果Poll阶段空闲，setImmediate可能会先执行。
```
const fs = require('fs');
```
fs.readFile(__filename, () => {
setTimeout(() => {
console.log(‘setTimeout in I/O’);
}, 0);
setImmediate(() => {
console.log(‘setImmediate in I/O’);
});
});

setTimeout(() => {
console.log(‘setTimeout outside I/O’);
}, 0);
setImmediate(() => {
console.log(‘setImmediate outside I/O’);
});

// 预期输出：
// setImmediate outside I/O (可能先于 setTimeout outside I/O，取决于 Poll 状态)
// setTimeout outside I/O (可能晚于 setImmediate outside I/O)
// setImmediate in I/O (总是先于 setTimeout in I/O)
// setTimeout in I/O
```
这个例子清晰地展示了，当一个I/O回调完成时，事件循环会优先处理`Check`阶段的`setImmediate`，然后才进入下一个循环周期去处理`Timers`阶段的`setTimeout`。
```

避免I/O回调内的阻塞：
如果在一个I/O回调中进行大量CPU密集型计算，这会阻塞Node.js的主线程，导致其他I/O事件无法及时处理。通过将这些计算分解，并使用setImmediate将部分计算推迟到下一个事件循环迭代，可以有效地“分片”工作，避免阻塞。

function heavyComputation(data) {
    // 模拟一个耗时操作
    let result = 0;
    for (let i = 0; i < 1e7; i++) {
        result += Math.sqrt(i);
    }
    console.log('Heavy computation done:', result);
}

// 错误的做法：直接在 I/O 回调中进行耗时计算
fs.readFile('/path/to/large/file.txt', (err, data) => {
    if (err) throw err;
    console.log('File read complete, starting heavy computation directly.');
    heavyComputation(data); // 阻塞主线程
    console.log('Direct computation finished.');
});

// 更好的做法：使用 setImmediate 分片
fs.readFile('/path/to/large/file.txt', (err, data) => {
    if (err) throw err;
    console.log('File read complete, scheduling heavy computation with setImmediate.');
    setImmediate(() => {
        heavyComputation(data); // 推迟到 Check 阶段执行
        console.log('Scheduled computation finished.');
    });
});

// 其他异步任务，例如一个 setTimeout
setTimeout(() => {
    console.log('Another task scheduled for setTimeout.');
}, 0);

在“错误的做法”中，heavyComputation会阻塞主线程，导致setTimeout的回调延迟执行。而在“更好的做法”中，heavyComputation被推迟到Check阶段，允许setTimeout在下一个Timers阶段更早地被处理，从而提高应用程序的响应性。

高级考量与实际应用

保持事件循环活跃：
事件循环只有在有“活跃”句柄（active handles）或待处理的请求（pending requests）时才会继续运行。活跃句柄包括打开的定时器、I/O连接（如TCP服务器、客户端socket）等。如果所有活跃句柄都关闭了，事件循环将退出，Node.js进程也将终止。
例如，一个net.createServer().listen()会创建一个活跃的网络句柄，从而保持事件循环运行。setTimeout()和setInterval()也会创建活跃的定时器句柄。setImmediate()本身也创建了一个uv_check_t句柄，这也能保持事件循环活跃，直到其回调被执行。
process.exit()：
process.exit()会立即终止Node.js进程，无论事件循环中是否还有待处理的任务。这应该谨慎使用，因为它会跳过所有清理工作（包括close回调）。
错误处理与事件循环：
未捕获的异常（uncaughtException）通常会导致Node.js进程退出。虽然可以通过process.on('uncaughtException', ...)来捕获，但通常不建议在生产环境中依赖它来“恢复”应用，因为它可能导致应用处于不确定状态。

总结与展望

Node.js的事件循环是其高性能异步架构的基石。通过深入理解其六个阶段，特别是Poll阶段与Check阶段在libuv层面的内核调用差异，我们能够更精确地预测代码的执行顺序，优化异步流程，并编写出更加健壮、高效的Node.js应用程序。

Poll阶段通过与操作系统内核的紧密协作，利用I/O多路复用机制实现了非阻塞I/O的等待和事件分发，是Node.js处理外部异步事件的门户。而Check阶段则是一个纯用户空间的内部机制，为setImmediate提供了一个高效且可预测的执行时机，非常适合用于非阻塞的任务分解。

掌握这些细节，将使您从Node.js的“使用者”晋升为“精通者”，能够更好地驾驭其异步特性，构建出色的应用。希望今天的讲座能为您带来新的启发和更深层次的理解。感谢大家的参与！