Day 2 - event loop 的巡场路线:六个 phase 与清场顺序

🗺️ 接上回:服务员巡场,有固定路线吗?

Day 1 我们知道了:Node.js 的服务员(event loop)永不等待,慢活外包给后厨,出餐按铃(回调)再回来收尾。

今天追问一步:铃可能同时响好多个 —— 定时器到点了、文件读完了、Promise 也完成了,服务员先处理哪个?他总不能看心情。答案是:他有一条雷打不动的巡场路线,每一圈都按同样的顺序经过固定的几站。这条路线,就是 event loop 的 phase(阶段)。

📇 概念卡:event loop 的六个 phase(只记三站)

event loop 每转一圈(iteration),按固定顺序经过 6 个 phase,每个 phase 是一个 FIFO 队列(该站排队等处理的铃铛):

   ┌───────────────────────────┐
┌─▶│  ① timers(定时器站)     │  到期的 setTimeout / setInterval
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │  ② pending callbacks      │  系统级回调(如 TCP 错误),日常碰不到
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │  ③ idle, prepare          │  Node 内部用,忽略
│  └─────────────┴─────────────┘
│  ┌─────────────┴─────────────┐
│  │  ④ poll(出餐取餐口)      │  I/O 回调:文件读完、网络响应到达
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │  ⑤ check(加急窗口)       │  setImmediate
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │  ⑥ close callbacks        │  关闭事件,如 socket.on('close')
│  └─────────────┬─────────────┘
└──┴─────────────┘ 下一圈

poll 站:整条路线的"中转站"

poll 是六站里最特殊的一站 —— 它是唯一会"停下来等"的地方。poll 队列空了之后,服务员怎么决定下一步?

1. 有 setImmediate 在排队 → 不等,直接去下一站 check;
2. 有快到期的 timer → 在 poll 等着,等到点了去 timers 站;
3. 什么活都没有 → 打烊(进程退出)。

第 1 条是今天第 4 节面试题的关键,先有个印象,待会儿实验验证。

✂️ 两个编外窗口:nextTick 与 microtask

上面六站是"正规军"。但还有两类回调不属于任何 phase,它们走的是"编外窗口" —— 每当服务员在一个站点服务完当前这批客人、动身去下一站之前,先把这两个窗口清空:

回忆 Day 1 笔记:await 之后的代码被打包成纸条挂在 Promise 的铃铛后面 —— 现在知道了,那张纸条走的就是 microtask 窗口。

⚖️ 经典面试题:setTimeout(0) vs setImmediate

两个都是"尽快执行",谁先?答案是后端面试的经典陷阱:看在哪儿注册。

在顶层注册:不确定

两个冷知识叠加出"不确定":

• setTimeout(fn, 0) 的 0 会被钳成 1ms,倒计时从调用那一刻起算;
• timers 站只接待已到期的铃铛。

loop 启动要花一点时间(加载模块等)。启动完巡到 timers 站时,那 1ms 过了没有?过了 → setTimeout 先;没过 → 一路空站到 check,setImmediate 先。同一台机器多跑几次,两种结果都可能出现。

在 I/O 回调里注册:确定,setImmediate 永远先

这正是第 2 节 poll 等待逻辑第 1 条的直接推论:poll 空了 + 有 setImmediate 排队 → 不等待,直奔 check。

☠️ 饿死 loop:为什么让出必须用 setImmediate

第 3 节说 nextTick 窗口"完全排空才放行"。如果排空过程中每次都再塞一张新单进去呢?

function keepCuttingInLine() {
  process.nextTick(keepCuttingInLine); // 店长无限插单
}
keepCuttingInLine(); // ⚠️ 别真跑:进程卡死,timer、I/O 全部饿死

nextTick 队列永远排不空 → 服务员永远动身不了 → 巡场路线停摆 → 整个进程卡死,和死循环一样致命。

正确的让出:setImmediate 分片

同样是递归,setImmediate 注册的是下一圈 check 站的活 —— 本圈照常走完,timer、I/O 都有机会在片间插入。这就是 Day 1"磨面粉"问题的止血方案:把大计算切成小块,每片结束用 setImmediate 让出。

记住分片只是止血。治本方案在 Day 1 已经说过:CPU 密集任务丢给 worker_threads(另雇一个磨粉工),那是本周后面几天的主题。

🌍 跨语言对照(调度思想 everywhere)

📌 面试翻译练习:面试官问 "Node 的 setImmediate 是什么?" 你可以答:"event loop check phase 的调度原语,语义等价于 C# 的 Task.Yield / Go 的 runtime.Gosched —— 都是'把剩下的活排到下一轮,先让调度器服务别人'的协作式让出。" 一个概念,四个生态通用。

🛠️ 今日习题(约 35 min)

习题代码在 src/02-event-loop-phases/,骨架已放好,带中文注释和预测填空。运行方式:npx tsx src/02-event-loop-phases/ex1-nexttick-vs-microtask.ts

✅ 总结与自测

今天带走的 4 句话

1. event loop 不是随机绕圈,是固定路线巡逻:timers → … → poll → check → close,一圈一圈永远如此。
2. 每站服务完、动身之前,先清空两个编外窗口:nextTick → microtask(但 ESM 顶层反序,microtask 先)。
3. setTimeout(0) vs setImmediate:顶层不确定,I/O 回调里 setImmediate 必胜 —— 因为 poll 的下一站固定是 check。
4. 让出执行权只能用 setImmediate/setTimeout(交给下一圈);递归 nextTick 会把清场变成无限循环,饿死整个进程。

自测清单(能打勾才算今天过关)

• 能画出 event loop 六站路线图,并说出日常三站各装什么
• 能解释"每站之间先清 nextTick 再清 microtask",以及 ESM 顶层为什么反序
• 能不查资料说清 setTimeout(0) vs setImmediate 在顶层和 I/O 回调里的两种结果及原因
• 能解释递归 nextTick 为什么卡死进程,以及分片让出的正确姿势
• 能把 setImmediate 翻译成 C#/Go 的等价物(Task.Yield / runtime.Gosched)