NodeJS中的异步方法

因为都是基于 V8 引擎，浏览器中包含的异步方式在 NodeJS 中也是一样的。另外 NodeJS 中还有一些其他常见异步形式。

文件 I/O：异步加载本地文件。
setImmediate()：与 setTimeout 设置 0ms 类似，在某些同步任务完成后立马执行。
process.nextTick()：在某些同步任务完成后立马执行。
server.close、socket.on(‘close’,…）等：关闭回调。

想象一下，如果上面的形式和 setTimeout、promise 等同时存在，如何分析出代码的执行顺序呢？只要我们理解了 NodeJS 的事件循环机制，也就清楚了。

事件循环模型

NodeJS 中 V8 引擎将 JS 代码解析后调用 Node API，然后 Node API 将任务交给 Libuv 去分配，最后再将执行结果返回给 V8 引擎。在 Libux 中实现了一套事件循环流程来管理这些任务的执行，所以 NodeJS 的事件循环主要是在 Libuv 中完成的。

事件循环各个阶段

timers 阶段：执行所有 setTimeout() 和 setInterval() 的回调。
pending callbacks 阶段：某些系统操作的回调，如 TCP 链接错误。除了 timers、close、setImmediate 的其他大部分回调在此阶段执行。
poll 阶段：轮询等待新的链接和请求等事件，执行 I/O 回调等。V8 引擎将 JS 代码解析并传入 Libuv 引擎后首先进入此阶段。如果此阶段任务队列已经执行完了，则进入 check 阶段执行 setImmediate 回调（如果有 setImmediate），或等待新的任务进来（如果没有 setImmediate）。在等待新的任务时，如果有 timers 计时到期，则会直接进入 timers 阶段。此阶段可能会阻塞等待。
check 阶段：setImmediate 回调函数执行。
close callbacks 阶段：关闭回调执行，如 socket.on(‘close’, …)。

const fs = require('fs');
fs.readFile(__filename, (data) => {
    // poll(I/O 回调) 阶段
    console.log('readFile')
    Promise.resolve().then(() => {
        console.error('promise1')
    })
    Promise.resolve().then(() => {
        console.error('promise2')
    })
});
setTimeout(() => {
    // timers 阶段
    console.log('timeout');
    Promise.resolve().then(() => {
        console.error('promise3')
    })
    Promise.resolve().then(() => {
        console.error('promise4')
    })
}, 0);
// 下面代码只是为了同步阻塞1秒钟，确保上面的异步任务已经准备好了
var startTime = new Date().getTime();
var endTime = startTime;
while(endTime - startTime < 1000) {
    endTime = new Date().getTime();
}
// 最终输出 timeout promise3 promise4 readFile promise1 promise2

setTimeout(() => {
  console.log('timeout1')
    Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0);
setTimeout(() => {
  console.log('timeout2')
    Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0);

浏览器中运行每次宏任务完成后都会优先处理微任务，输出“timeout1”、“promise1”、“timeout2”、“promise2”。
NodeJS 中运行因为输出 timeout1 时，当前正处于 timers 阶段，所以会先将所有 timer 回调执行完之后再执行微任务队列，即输出“timeout1”、“timeout2”、“promise1”、“promise2”。

上面的差异可以用浏览器和 NodeJS 10 对比验证。是不是感觉有点反程序员？因此 NodeJS 在版本 11 之后，就修改了此处逻辑使其与浏览器尽量一致，也就是每个 timer 执行后都先去检查一下微任务队列，所以 NodeJS 11 之后的输出已经和浏览器一致了。

nextTick、setImmediate 和 setTimeout

setImmediate: check阶段执行的
process.nextTick()：可以想象是把 nextTick 的任务放到了当前循环的后面，与 promise.then() 类似，但比 promise.then() 更前面。意思就是在当前同步代码执行完成后，不管其他异步任务，先尽快执行 nextTick
setTimeout(): time阶段执行的

setTimeout(() => {
    console.log('timeout');
}, 0);
Promise.resolve().then(() => {
    console.error('promise')
})
process.nextTick(() => {
    console.error('nextTick')
})
// 输出：nextTick、promise、timeout

setTimeout(() => {
  console.log('timeout');
}, 0);
setImmediate(() => {
  console.log('setImmediate');
});
// 输出：timeout、 setImmediate

const fs = require('fs');
fs.readFile(__filename, (data) => {
    console.log('readFile');
    setTimeout(() => {
        console.log('timeout');
    }, 0);
    setImmediate(() => {
        console.log('setImmediate');
    });
});
// 输出：readFile、setImmediate、timeout

第一轮循环没有需要执行的异步任务队列；
第二轮循环 timers 等阶段都没有任务，只有 poll 阶段有 I/O 回调任务，即输出“readFile”；
参考前面事件阶段的说明，接下来，poll 阶段会检测如果有 setImmediate 的任务队列则进入 check 阶段，否则再进行判断，如果有定时器任务回调，则回到 timers 阶段，所以应该进入 check 阶段执行 setImmediate，输出“setImmediate”；
然后进入最后的 close callbacks 阶段，本次循环结束；
最后进行第三轮循环，进入 timers 阶段，输出“timeout”。

前端知识总结

Node事件循环

NodeJS中的异步方法

事件循环模型

事件循环各个阶段

nextTick、setImmediate 和 setTimeout