为何Poll队列非空时事件循环仍进入Check阶段？代码执行结果存疑

测试代码 #

fs.readFile('./1.js', (err, data) => {
    console.log('starta');
    setTimeout(() => console.log('settimeouta'), 20);
    const now = new Date();
    while (new Date() - now < 1000) {}
    console.log('before setIa')
    setImmediate(() => {console.log('setImmediatea')})
});
fs.readFile('./1.js', (err, data) => {
    console.log('startb');
    setTimeout(() => console.log('settimeoutb'), 20);
    const now = new Date();
    while (new Date() - now < 1000) {}
    console.log('before setIb')
    setImmediate(() => {console.log('setImmediateb')})
});
fs.readFile('./1.js', (err, data) => {
    console.log('startc');
    setTimeout(() => console.log('settimeoutc'), 20);
    const now = new Date();
    while (new Date() - now < 1000) {}
    console.log('before setIc')
    setImmediate(() => {console.log('setImmediatec')})
});

问题背景 #

1.js文件体积极小，理论上三个fs.readFile的I/O回调应都能及时进入Poll队列，但实际执行顺序与预期不符：

预期执行顺序 #

• starta
• before setIa
• startb
• before setIb
• startc
• before setIc
• setImmediatea
• setImmediateb
• setImmediatec
• settimeouta
• settimeoutb
• settimeoutc

实际可能的执行顺序 #

• starta
• before setIa
• setImmediatea
• settimeouta
• startc
• before setIc
• setImmediatec
• settimeoutc
• startb
• before setIb
• setImmediateb
• settimeoutb

现象原因解释 #

1. 事件循环的阶段执行规则 #

Node.js事件循环按固定顺序循环处理各个阶段的回调，每个阶段会一次性处理完当前队列的所有回调（或达到系统执行上限），再进入下一个阶段，阶段顺序为：
Timers → Pending Callbacks → Idle/Prepare → Poll → Check → Close Callbacks

2. I/O回调的实际入队时机 #

虽然文件很小，但底层操作系统的I/O线程调度存在微小延迟，三个fs.readFile的I/O操作不会绝对同时完成：

• 第一个I/O操作最先完成，其回调率先进入Poll队列；
• 另外两个I/O操作的完成时间，刚好落在第一个回调执行的1秒while阻塞期间——当第一个回调执行完毕时，这两个回调才刚被加入Poll队列。

3. 实际执行流程拆解 #

• 主代码执行完三个fs.readFile后，事件循环启动，进入第一轮循环：
  • Timers阶段：无到期回调，直接跳过；
  • 进入Poll阶段：此时只有starta的回调在队列中，执行它：
    • 打印starta，设置20ms延迟的setTimeout；
    • 进入1秒阻塞，此时20ms早已到期，settimeouta回调被加入Timers队列；
    • 打印before setIa，调用setImmediate，其回调被加入Check队列；
  • 第一个回调执行完毕后，Poll队列才刚收到另外两个回调，但事件循环会继续走完当前轮的剩余阶段：
    • Check阶段：执行setImmediatea并打印；
    • Close Callbacks阶段：无任务，跳过；
• 第一轮循环结束，回到Timers阶段：执行已到期的settimeouta并打印；
• 进入第二轮循环：再次到达Poll阶段，此时startc的回调在队列中，重复上述流程，执行完后处理Check和Timers阶段的对应回调；
• 第三轮循环处理最后一个startb的回调，最终形成你看到的实际执行顺序。

4. 预期偏差的根源 #

你假设三个I/O回调会同时进入Poll队列，事件循环会在Poll阶段一次性执行完所有回调再处理后续阶段。但实际因为底层I/O调度的延迟，另外两个回调是在第一个回调的阻塞期间才入队的，导致事件循环只能分多轮处理每个I/O回调，每处理完一个就走完后续阶段，再回到Poll处理下一个。

Poll阶段的检测顺序与优先级 #

Poll阶段是事件循环的核心处理阶段，执行逻辑如下：

1. 优先处理已入队的I/O回调：如果Poll队列不为空，事件循环会持续执行队列中的回调，直到队列为空或达到系统限制的执行次数；
2. 队列空时的等待逻辑：
   • 如果存在setImmediate回调，事件循环会立即结束Poll阶段，进入Check阶段执行这些回调；
   • 如果没有setImmediate回调，事件循环会等待新的I/O事件触发，直到有事件到来，或者有Timers到期（此时会跳回Timers阶段处理）；
3. 回调执行中的队列更新：在执行Poll队列中的回调时，新加入的I/O回调不会被立即执行，需等到下一次事件循环进入Poll阶段时才会被处理。

内容的提问来源于stack exchange，提问作者Mr.Wang