事件循环中的“检查”阶段是什么？-js教程-PHP中文网

事件循环的“检查”阶段专为setimmediate()回调设计，位于i/o操作（轮询阶段）之后、下一循环（定时器阶段）之前；2. 在i/o回调内，setimmediate比settimeout(0)先执行，因前者进入当前循环的检查阶段，后者推迟到下一循环的定时器阶段；3. 在顶层代码中两者执行顺序不确定，取决于系统调度；4. setimmediate适用于i/o后非阻塞延时操作和拆分耗时任务，防止事件循环饥饿，提升应用响应性。

事件循环中的“检查”阶段是什么？

事件循环中的“检查”（check）阶段，在Node.js里，它主要就是为setImmediate()的回调函数准备的。你可以把它理解成一个专门的“插队”点，它在I/O操作的回调执行完毕之后，但在下一个事件循环周期开始之前，给那些急着想在当前I/O处理完后立刻执行的任务一个机会。

解决方案

要深入理解“检查”阶段，我们得把它放到整个Node.js事件循环的语境里看。简单来说，事件循环就像一个永不停歇的流水线，它有几个固定的“工位”：

定时器（timers）：处理setTimeout()和setInterval()的回调。
待定回调（pending callbacks）：处理一些系统操作的回调，比如TCP错误。
空闲、准备（idle, prepare）：内部使用。
轮询（poll）：这是核心，大部分I/O事件（文件读写、网络请求等）的回调都在这里等待执行。当轮询队列空了，或者达到了某个条件，它就会决定是等待新的I/O事件，还是进入下一个阶段。
检查（check）：就是我们说的这个阶段，专门用来执行setImmediate()设定的回调。
关闭回调（close callbacks）：处理一些关闭事件，比如socket.on('close', ...)。

“检查”阶段的独特之处在于，它紧跟在“轮询”阶段之后。这意味着，如果你在一次I/O操作的回调中调用了setImmediate()，那么这个setImmediate()的回调函数，会在当前轮询队列中的其他I/O回调都执行完毕后，立即执行，而不需要等到下一个事件循环周期。这和setTimeout(fn, 0)在某些场景下的表现会非常不同。

举个例子，假设你正在处理一个文件读取：

const fs = require('fs');

fs.readFile('/path/to/some/file.txt', () => {
  console.log('文件读取完成回调');

  setImmediate(() => {
    console.log('setImmediate 在文件读取回调内部');
  });

  setTimeout(() => {
    console.log('setTimeout(0) 在文件读取回调内部');
  }, 0);
});

console.log('程序开始');

登录后复制

在这个例子里，'程序开始'会先打印。然后，当文件读取完成，'文件读取完成回调'会打印。紧接着，你会发现'setImmediate 在文件读取回调内部'会比'setTimeout(0) 在文件读取回调内部'先打印。这是因为setImmediate的回调被安排在了当前事件循环的“检查”阶段，而setTimeout(0)的回调则被安排到了下一个事件循环的“定时器”阶段。

setImmediate() 和 setTimeout() 有何不同？

这是个老生常谈的问题，但每次讲到事件循环，它都绕不开。最核心的区别在于它们在事件循环中的“落脚点”不同。setTimeout(fn, 0)（或者任何非零延迟的setTimeout，只要延迟时间到了）的回调会被安排到“定时器”阶段执行。而setImmediate(fn)的回调则被安排到“检查”阶段。

这个差异在两种特定场景下会表现得尤为明显：

场景一：在I/O回调内部

就像上面那个文件读取的例子，如果你在fs.readFile的回调函数里同时调用setImmediate和setTimeout(0)，那么setImmediate的回调总是会先执行。这是因为当I/O回调执行时，事件循环已经处于“轮询”阶段。setImmediate的回调会被推入“检查”阶段的队列，这个阶段紧跟在“轮询”之后。而setTimeout(0)的回调则被推入“定时器”阶段的队列，这个阶段要等到下一个事件循环周期才会到来。

const fs = require('fs');

fs.readFile(__filename, () => { // 读取当前文件
  setImmediate(() => {
    console.log('I/O 内部：setImmediate');
  });
  setTimeout(() => {
    console.log('I/O 内部：setTimeout(0)');
  }, 0);
});

// 输出通常是：
// I/O 内部：setImmediate
// I/O 内部：setTimeout(0)

登录后复制

场景二：在主模块代码中（非I/O回调内部）

如果你在顶级作用域（也就是没有被任何I/O回调包裹）直接调用它们，情况可能会变得有点“不确定”。这取决于系统性能和当前事件循环的状态。理论上，setTimeout(0)可能会先执行，因为它在“定时器”阶段，而“定时器”阶段在“检查”阶段之前。但实际上，由于setTimeout(0)的延迟是“最小延迟”，它可能需要一些时间来调度，导致setImmediate反而先执行。

阶跃AI

阶跃星辰旗下AI智能问答搜索助手

291

查看详情

setImmediate(() => {
  console.log('顶层：setImmediate');
});
setTimeout(() => {
  console.log('顶层：setTimeout(0)');
}, 0);

// 输出可能是：
// 顶层：setTimeout(0)
// 顶层：setImmediate
// 也可能是：
// 顶层：setImmediate
// 顶层：setTimeout(0)
// 这种不确定性是存在的，但在I/O回调内，setImmediate的确定性更高。

登录后复制

所以，关键在于上下文。在I/O操作的回调中，setImmediate提供了更可预测的行为，它保证了在当前I/O操作完成后立即执行，而不是等到下一个事件循环周期。

事件循环中‘检查’阶段的执行顺序如何？

为了更清楚地理解“检查”阶段的执行顺序，我们不妨把整个事件循环的宏观流程再梳理一遍，看看它究竟处于哪个位置，以及它前后都有什么。

一个完整的事件循环周期大致是这样的：

timers (定时器)：这个阶段处理那些通过 setTimeout() 和 setInterval() 设定的回调。系统会检查当前时间，看是否有定时器到期，然后执行它们的回调。
pending callbacks (待定回调)：处理一些操作系统级别的回调，比如TCP连接错误。
idle, prepare (空闲、准备)：这个阶段是Node.js内部使用的，你通常不需要关心它。
poll (轮询)：这是事件循环中非常关键的一个阶段。
- 它首先会执行几乎所有I/O相关的回调（除了close回调、setImmediate设定的回调以及少数系统级回调）。比如文件读取完成、网络请求响应、数据库查询结果等等。
- 如果轮询队列是空的（即没有待处理的I/O事件），它会检查是否有setImmediate()的回调在等待。如果有，它会立即进入“检查”阶段。
- 如果没有setImmediate()的回调，它可能会阻塞在这里，等待新的I/O事件发生。
check (检查)：这就是我们讨论的阶段。它专门用于执行 setImmediate() 注册的回调函数。这个阶段的存在，确保了 setImmediate() 可以在当前I/O操作完成后，且在下一个事件循环周期开始前，得到执行。
close callbacks (关闭回调)：处理一些close事件的回调，比如socket.on('close', ...)。

需要特别指出的是，process.nextTick()和Promise的微任务（microtasks）并不属于上述任何一个阶段。它们有自己的优先级：

process.nextTick()：它的回调会在当前操作完成后，且在事件循环的任何阶段开始之前立即执行。它拥有最高的优先级，甚至高于Promise的微任务。如果在一个阶段（比如“定时器”阶段）执行了一个回调，这个回调中调用了process.nextTick()，那么nextTick的回调会在当前阶段的其他操作（如果有的话）和下一个阶段之间执行。
Promise微任务：Promise的then()、catch()、finally()回调，以及async/await中的await之后的代码，都属于微任务。它们会在当前宏任务（即事件循环的一个阶段）执行完毕后，但在下一个宏任务阶段开始之前，被清空。

所以，“检查”阶段的执行顺序是：在“轮询”阶段处理完I/O回调后，但在“关闭回调”阶段之前。而process.nextTick和Promise微任务则是在每个阶段之间，或者说在当前代码执行流的间隙中，尽可能快地执行。这种分层和优先级的设计，是Node.js非阻塞I/O和高性能的关键。

何时应该使用 setImmediate()？

理解了setImmediate()在事件循环中的位置和它的特性，我们就能更好地判断何时应该使用它。它不是一个万能的解决方案，但在某些特定场景下，它能提供比setTimeout(0)更可靠、更符合预期的行为。

主要的使用场景有：

在I/O回调内部进行非阻塞的延时操作：这是setImmediate()最经典也是最推荐的使用场景。当你需要在一次I/O操作（比如文件读取、网络请求）的回调函数中，执行一些耗时但不希望阻塞当前事件循环的代码时，setImmediate()是一个非常好的选择。它能保证这些代码在当前I/O处理完成后立刻执行，而不会被推迟到下一个事件循环周期，这比setTimeout(0)在这种情况下更具确定性。
```
const fs = require('fs');

fs.readFile('/path/to/large/file.txt', (err, data) => {
  if (err) throw err;
  console.log('文件读取完成，开始处理数据...');

  // 假设data处理非常耗时，但我们不希望阻塞事件循环
  setImmediate(() => {
    // 模拟一个耗时操作
    let sum = 0;
    for (let i = 0; i < 1e7; i++) { // 1千万次循环
      sum += i;
    }
    console.log('数据处理完成，结果：', sum);
  });

  console.log('文件读取回调即将结束，setImmediate已安排。');
});

console.log('程序启动，等待文件I/O...');
```
登录后复制
这样，即使数据处理很耗时，它也不会阻塞文件读取回调的返回，从而允许事件循环继续处理其他I/O事件或进入下一个阶段。

分解大型同步任务，防止事件循环饥饿：如果你的应用程序中有一个非常大的、计算密集型的同步函数，它可能会长时间霸占CPU，导致事件循环无法及时处理其他事件（比如网络请求、用户输入等），从而让应用程序看起来“卡住”了。你可以利用setImmediate()将这个大任务分解成多个小块，在每个小块处理完毕后，通过setImmediate()调度下一个小块。这相当于给事件循环一个“喘息”的机会。

function processLargeArray(arr) {
  let index = 0;
  const chunkSize = 1000; // 每次处理1000个元素

  function processChunk() {
    const start = index;
    const end = Math.min(index + chunkSize, arr.length);

    for (let i = start; i < end; i++) {
      // 模拟处理单个元素
      // console.log(`处理元素: ${arr[i]}`);
    }

    index = end;

    if (index < arr.length) {
      setImmediate(processChunk); // 调度下一个块
    } else {
      console.log('数组处理完毕！');
    }
  }

  processChunk(); // 启动第一个块
}

const largeArray = Array.from({ length: 100000 }, (_, i) => i);
console.log('开始处理大型数组...');
processLargeArray(largeArray);
console.log('大型数组处理函数已返回，事件循环可以继续。');

登录后复制

这种模式被称为“cooperative multitasking”（协作式多任务），它允许Node.js在执行长时间任务时，依然保持对其他事件的响应能力。

确保某个回调在当前脚本执行完毕后，但尽可能早地执行：有时你希望一个函数在当前同步代码块执行完毕后立即运行，但又不想它阻塞当前代码流。setImmediate()可以在这种情况下提供比process.nextTick()更“宽松”的调度，因为它允许其他微任务和当前阶段的剩余操作先完成。