前言
事件驱动、异步、单线程、非阻塞I/O，这是我们听得最多的关于nodejs的介绍。看到这些关键字，可能我们会好奇："nodejs既然是单线程，那是怎么实现异步非阻塞的？" 这全都依赖于nodejs有一个非常强大的机制。它的名字叫做Event Loop，那Event Loop又是什么东西呢？
开篇之前我们先来看一道题目:
看到这道题目是不是有种熟悉的感觉，相信这一类的题目在各大论坛以及面试题上面大家都有看到过。我们可以用一两分钟来思索一下这道题目的答案，然后看看最终结果是否与你解答的相同。
// 请输出以下代码的执行结果
console.log('1');
process.nextTick(function() {
console.log('2');
});
setTimeout(() => {
console.log('3');
}, 0);
async function async1() {
console.log('4');
await async2();
console.log('5');
}
async function async2() {
console.log('6');
}
async1();
new Promise(function(resolve) {
console.log('7')
resolve();
}).then(function() {
console.log('8')
});
console.log('9');
正确的答案为 (注: 我们的运行环境是node12，低版本运行的结果会有所差异)
心里想: "这道题怎么可能难得住我"，一顿操作猛如虎之后，信誓旦旦的瞄了一下正确答案，发现居然全TM错了！
为啥和我们想象中的不太一样、难道是我们打开的方式不对？触及到我们知识的底线了，吓得我赶紧打开了google搜索...
原来上面这道题正是考察着我们对node事件循环机制的了解，主要是javascript函数在node中执行顺序的问题，其中包括setTimeout，process.nextTick，async/await，promise。同时也考察着我们对node事件循环机制的了解。既然如此，下面我们就来一起探讨一下nodejs的Event Loop。
NodeJS运行机制
在了解事件循环之前，我们先来简单的了解一下node是如何工作的
根据上图我们简单做出以下总结:
1.我们写的js代码会交给v8引擎进行处理
2.解析后的代码会调用NodeApi，再交由libuv库去执行
3.libuv会将不同的任务分配给不同的线程，形成一个事件循环(Event Loop)。
4.任务处理完成后会以异步的方式将执行结果返回给V8引擎、再由v8返回给我们。
由此，我们可以知道，Node中的Event Loop(事件循环)是由底层的libuv库负责执行的，关于libuv库本篇文章就不做探索了，有兴趣的兄dei可自行挖掘。
下面我们就来进入今天的主角-Event Loop
什么是Event Loop
Event Loop即为事件循环，指的是Node中解决javascript单线程运行时不会阻塞的一种机制，也就是node异步的原理。
在了解 Event Loop 之前，我们先来熟悉一下执行栈和事件队列这两个概念。
执行栈
当我们调用一个方法的时候，js会生成一个与这个方法相对应的执行环境。
而当一系列方法被依次调用的时候，因为js是单线程的，同一时间只能执行一个方法，于是这些方法被排队在一个单独的地方。这个地方被称为执行栈。
事件队列
当我们发起异步请求后，主线程并不会一直等待其返回结果，而是会将这个事件挂起，继续执行执行栈中的其他任务。等异步任务返回结果后，该异步任务按照执行顺序，加入到与执行栈不同的另一个队列，这个队列被称为事件队列。
这里我们需要明确以下几个概念：
1、在Node环境中javascript运行的线程是单线程的，事件循环的线程也是单线程的，但这两个不是一个线程。
2、在事件队列中，任务又分为宏任务和微任务：
宏任务：setTimeout，setInterval，I/O操作，setImmediate...
微任务：process.nextTick(优先级最高)、promise.then、await...
3、主线程会先将执行栈中的同步任务清空，当执行栈中的任务清空，主线程会先检查微任务队列中是否有任务，如果有，就将微任务队列中的任务依次执行，直到微任务队列为空，之后再检查宏任务队列中是否有任务，如果有，则每次取出第一个宏任务加入到执行栈中，之后再清空执行栈，检查微任务，以此循环... ...
Event Loop说明
看完上面的概念蒙圈了，什么意思呢？我们再来举个简单的🌰
console.log('1');
setTimeout(() => {
console.log('2');
}, 0);
process.nextTick(() => {
console.log('3');
process.nextTick(() => {
console.log('4');
});
});
console.log('5');
// 输出结果: 1、5、3、4、2
我们来分析一些这个执行结果。
1、按照js由上到下的执行顺序，先遇到同步任务console输出1。
2、接着遇到setTimeout，setTimeout是宏任务，会先放到宏任务队列中。然后遇到process.nextTick是微任务，会放入微任务队列中。
3、继续向下执行输出5。现在执行栈中的任务已经清空，由于微任务的优先级高于宏任务，所以会先执行process.nextTick，输出3。
4、执行后发现立马又触发了一个异步任务process.nextTick，继续将其放入微任务队列中，上面说过，我们在开始一个宏任务之前需要将微任务都清空，所以会继续检查微任务队列，输出4。
5、这时微任务队列可算清空了，执行宏任务，输出2
总的概括为: 执行所有同步任务 -> 清空所有微任务 -> 执行一个宏任务 -> 清空所有微任务 -> 执行一个宏任务...清空所有微-> 执行一个宏...以此循环
Event Loop循环任务
上面我们讲述了执行栈和事件队列之间运作的关系，那事件队列中都有哪些任务呢？
我们再来看一张图，描述了Node中事件循环的具体流程：
通过上图我们总结一下:
1、事件循环一共有6个阶段，每个阶段都有自己特有的操作。
2、当事件循环进行到某个阶段时，会执行该阶段队列中的回调，直到队列空了或者达到了执行次数限制。
3、事件循环在进入下一个阶段前，会检查是否有microtask，如果有，全部执行、然后进入下一个阶段，循环往复。
我们重点看timers、poll、check这3个阶段就好。
理论太枯燥了，我们通过下面的例子来实践一下：
fs.readFile(__filename, () => {
console.log('1');
setTimeout(() => {
console.log('3')
}, 0);
setImmediate(() => {
console.log('2')
})
process.nextTick(() => {
console.log('4');
});
});
console.log('5');
// 执行结果：5、1、4、2、3
我们接着来分析上面的例子：
1、先遇到读取文件的异步操作，跳过，直接输出5。
2、文件读取完成后，回调事件加入了事件队列，这时事件循环到了poll阶段，触发回调事件，输出1。
3、继续往下执行分别遇到setTimeout和setImmediate，都是宏任务，回调加入事件队列
4、再往下执行遇到process.nextTick，回调加入微任务队列
5、这时事件轮询接着运作，刚才是在poll阶段将回调处理完，进入check阶段，但是我们之前说过，在进入每个阶段之前需要清空微任务队列，这时候发现微任务队列中有process.nextTick，输出4
6、微任务队列清空，正式进入check阶段、输出2、这时候没有微任务了，该轮循环结束，但是发现事件队列中还有任务，开始进入下一轮循环
7、新的一轮循环由timers阶段开始，发现有对应的setTimeout回调，输出3
额外补充
1、同一次事件循环中，微任务永远在宏任务之前执行。
2、process.nextTick：process.nextTick会在当前操作完成后立刻执行，也就意味着在事件队列每个阶段中，他的优先级永远高于其他任务。
console.log('1');
setTimeout(function(){
console.log('2');
},0)
process.nextTick(function() {
console.log('3');
});
// 执行结果：1、3、2
3、promise和async中的立即执行，我们知道promise中的异步体现在then和catch中，所以写在promise中的代码是被当做同步任务立即执行的。而在async/await中，在出现await出现之前，其中的代码也是立即执行的。再举个🌰
console.log('1');
async function async1() {
console.log('2');
await async2();
console.log('3');
}
async function async2() {}
async1();
new Promise(function(resolve) {
console.log('4')
resolve();
})
console.log('5')
// 执行结果: 1、2、4、5、3
4、setTimeout和setImmediate执行是靠“随缘法则”
setTimeout(() => {
console.log('setTimeout');
},0)
setImmediate(() => {
console.log('setImmediate');
})
//在node环境中，多次执行上面的代码，就会发现如下两种结果：
//（1）先输出setTimeout，后输出setImmediate
//（2）先输出setImmediate，后输出setTimeout
看完这里的我已经一脸懵逼了, 不是说setTimeout属于timers阶段、setImmediate属于check阶段吗，按道理来讲，应该是先输出timeout，再输出immediate，怎么还会随机的？这啥玩意这是？不按套路出牌啊！
这时候我们只能故作镇定，默默的打开了google搜索...
原来事件循环每一次都有个时间间隔。这取决于当前 CPU 给分配的时间片长短。它可能再1ms 内循环多次，也可能大于 1ms 才循环一次。那就有可能存在以下两种情况:
1、在第一轮循环，timers阶段开始，setTimeout还没到触发时间，因此跳过setTimeout，进入check阶段触发setImmediate，接着开始新的一轮循环，进入timers阶段，发现setTimeout已经过期了，立即触发setTimeout，因此就会出现setImmediate早于setTimeout
2、在第一轮循环，timers阶段开始，setTimeout正好时间到了(或者已经过期)，立即触发setTimeout，然后进入check阶段触发setImmediate，因为就会出现setTimeout早于setImmediate
5、setTimeout和setImmediate嵌套在IO操作中
var fs = require('fs')
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
});
// 结果setImmediate永远先于setTimeout执行
咦！怎么又和上面的随缘法则不一样了，继续一脸懵逼！！！原来是因为fs.readFile的回调是在poll阶段执行的，当其回调执行完毕之后，poll队列为空，
接着进入check阶段，输出immediate，之后在下一个事件循环在timers阶段中输出timeout。
6、事件队列中存放的是异步任务的回调函数
总结
以上就是我个人对node事件循环的一些看法，涵盖的知识点比较多，我认为重点就在于要理解好每个循环阶段的工作，清楚的了解了事件循环的执行顺序和每一个阶段的特点，可以使我们对一段异步代码的执行顺序有一个清晰的认识。如有不对的地方欢迎各位大虾互相讨论学习。
最后的最后，我们再回头看一下开篇的题目，相信各位仁兄一定胸有成竹了吧。
