事件循环（Event Loop）是 Node.js 最核心的概念，所以理解 Event Loop 如何运作对于写出正确的代码和调试是非常重要的。比如考虑以下代码：
setTimeout(() => { console.log('hi') }, 1000) ...
我们期望程序运行 1s 后打印出 hi，但是实际情况可能是远大于 1s 后才打印出 hi。这个时候如果理解 Event Loop 就可以轻易发现问题，否则任凭怎么调试都是发现不了问题的。
Event Loop 可以简单理解为：
小提示：我们常说 Node.js 是单线程的，但为何能达到高并发呢？原因就在于底层的 Libuv 维护一个 I/O 线程池（即上述的 “任务队列”），结合 Node.js 异步 I/O 的特性，单线程也能达到高并发啦。
上面提到了 “读取任务队列”，这样讲有点笼统，其实 Event Loop 的 “读取任务队列” 有 6 个阶段，如下所示：
┌───────────────────────┐ ┌─>│ timers │ │ └──────────┬────────────┘ │ ┌──────────┴────────────┐ │ │ I/O callbacks │ │ └──────────┬────────────┘ │ ┌──────────┴────────────┐ │ │ idle, prepare │ │ └──────────┬────────────┘ ┌───────────────┐ │ ┌──────────┴────────────┐ │ incoming: │ │ │ poll │<─────┤ connections, │ │ └──────────┬────────────┘ │ data, etc. │ │ ┌──────────┴────────────┐ └───────────────┘ │ │ check │ │ └──────────┬────────────┘ │ ┌──────────┴────────────┐ └──┤ close callbacks │ └───────────────────────┘
每个阶段都有一个 FIFO 的回调队列（queue），当 Event Loop 执行到这个阶段时，会从当前阶段的队列里拿出一个任务放到栈中执行，当队列任务清空，或者执行的回调数量达到上限后，Event Loop 会进入下个阶段。
每个阶段（phase）的作用：
poll 阶段主要有两个功能：
如果 Event Loop 进入了 poll 阶段，且代码未设定 timer，可能发生以下情况：
一旦 poll queue 为空，Event Loop 将检查 timers，如果有 timer 的时间到期，Event Loop 将回到 timers 阶段，然后执行 timer queue。
上面的 6 个阶段并没有出现 process.nextTick()，process.nextTick() 不在 Event Loop 的任何阶段执行，而是在各个阶段切换的中间执行，即从一个阶段切换到下个阶段前执行。这里还需要提一下 macrotask 和 microtask 的概念，macrotask（宏任务）指 Event Loop 每个阶段执行的任务，microtask（微任务）指每个阶段之间执行的任务。即上述 6 个阶段都属于 macrotask，process.nextTick() 属于 microtask。
小提示：process.nextTick() 的实现和 v8 的 microtask 并无关系，是 Node.js 层面的东西，应该说 process.nextTick() 的行为接近为 microtask。Promise.then 也属于 microtask 的一种。
最后，放出一张关于 Event Loop 非常直观的图：
绿色小块表示 Event Loop 的各个阶段，执行的是 macrotask，macrotask 中间的粉红箭头表示执行的是 microtask。
下面我们以六道题巩固一下前面讲到的 Event Loop 的知识。
setTimeout(() => { console.log('setTimeout') }, 0) setImmediate(() => { console.log('setImmediate') })
运行结果：
setImmediate setTimeout
或者：
setTimeout setImmediate
为什么结果不确定呢？
解释：setTimeout/setInterval 的第 2 个参数取值范围是：[1, 2^31 - 1]，如果超过这个范围则会初始化为 1，即 setTimeout(fn, 0) === setTimeout(fn, 1)。我们知道 setTimeout 的回调函数在 timer 阶段执行，setImmediate 的回调函数在 check 阶段执行，event loop 的开始会先检查 timer 阶段，但是在开始之前到 timer 阶段会消耗一定时间，所以就会出现两种情况：
再看个例子：
setTimeout(() => { console.log('setTimeout') }, 0) setImmediate(() => { console.log('setImmediate') }) const start = Date.now() while (Date.now() - start < 10);
运行结果一定是：
const fs = require('fs') fs.readFile(__filename, () => { setTimeout(() => { console.log('setTimeout') }, 0) setImmediate(() => { console.log('setImmediate') }) })
解释：fs.readFile 的回调函数执行完后：
所以，在 I/O Callbacks 中注册的 setTimeout 和 setImmediate，永远都是 setImmediate 先执行。
setInterval(() => { console.log('setInterval') }, 100) process.nextTick(function tick () { process.nextTick(tick) })
运行结果：setInterval 永远不会打印出来。
解释：process.nextTick 会无限循环，将 event loop 阻塞在 microtask 阶段，导致 event loop 上其他 macrotask 阶段的回调函数没有机会执行。
解决方法通常是用 setImmediate 替代 process.nextTick，如下：
setInterval(() => { console.log('setInterval') }, 100) setImmediate(function immediate () { setImmediate(immediate) })
运行结果：每 100ms 打印一次 setInterval。
解释：process.nextTick 内执行 process.nextTick 仍然将 tick 函数注册到当前 microtask 的尾部，所以导致 microtask 永远执行不完； setImmediate 内执行 setImmediate 会将 immediate 函数注册到下一次 event loop 的 check 阶段，而不是当前正在执行的 check 阶段，所以给了 event loop 上其他 macrotask 执行的机会。
setImmediate(() => { console.log('setImmediate1') setImmediate(() => { console.log('setImmediate2') }) process.nextTick(() => { console.log('nextTick') }) }) setImmediate(() => { console.log('setImmediate3') })
setImmediate1 setImmediate3 nextTick setImmediate2
注意：并不是说 setImmediate 可以完全代替 process.nextTick，process.nextTick 在特定场景下还是无法被代替的，比如我们就想将一些操作放到最近的 microtask 里执行。
const promise = Promise.resolve() .then(() => { return promise }) promise.catch(console.error)
TypeError: Chaining cycle detected for promise #<Promise> at <anonymous> at process._tickCallback (internal/process/next_tick.js:188:7) at Function.Module.runMain (module.js:667:11) at startup (bootstrap_node.js:187:16) at bootstrap_node.js:607:3
解释：Promise A+ 的规范里规定 promise 不能返回自己。仔细想想，即使规范里不规定，promise.then 类似于 process.nextTick，都会将回调函数注册到 microtask 阶段。上面代码也会导致死循环，类似前面提到的：
process.nextTick(function tick () { process.nextTick(tick) })
const promise = Promise.resolve() promise.then(() => { console.log('promise') }) process.nextTick(() => { console.log('nextTick') })
nextTick promise
解释：promise.then 虽然和 process.nextTick 一样，都将回调函数注册到 microtask，但优先级不一样。process.nextTick 的 microtask queue 总是优先于 promise 的 microtask queue 执行。
setTimeout(() => { console.log(1) }, 0) new Promise((resolve, reject) => { console.log(2) for (let i = 0; i < 10000; i++) { i === 9999 && resolve() } console.log(3) }).then(() => { console.log(4) }) console.log(5)
2 3 5 4 1
解释：Promise 构造函数是同步执行的，所以先打印 2、3，然后打印 5，接下来 event loop 进入执行 microtask 阶段，执行 promise.then 的回调函数打印出 4，然后执行下一个 macrotask，恰好是 timer 阶段的 setTimeout 的回调函数，打印出 1。
setImmediate(() => { console.log(1) setTimeout(() => { console.log(2) }, 100) setImmediate(() => { console.log(3) }) process.nextTick(() => { console.log(4) }) }) process.nextTick(() => { console.log(5) setTimeout(() => { console.log(6) }, 100) setImmediate(() => { console.log(7) }) process.nextTick(() => { console.log(8) }) }) console.log(9)
9 5 8 1 7 4 3 6 2
process.nextTick、setTimeout 和 setImmediate 的组合，请读者自行推理吧。
上一节：3.5 Rust Addons
下一节：3.7 uncaughtException + llnode
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8