前言

事件驱动、异步、单线程、非阻塞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');

正确的答案为顺序为 1、4、6、7、9、2、5、8、3  (注: 我们的运行环境是node15.6，低版本运行的结果会有所差异)。

上面这道题正是考察着我们对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库本篇文章就不做探索了，有兴趣的同学可自行挖掘学习。

下面我们就来进入今天的主角-Event Loop。

什么是事件循环（Event Loop）

事件循环（Event Loop）是 Node.js 处理非阻塞 I/O 操作的机制——尽管 JavaScript 是单线程处理的——当有可能的时候，它们会把操作转移到系统内核中去。

既然目前大多数内核都是多线程的，它们可在后台处理多种操作。当其中的一个操作完成的时候，内核通知 Node.js 将适合的回调函数添加到 轮询 队列中等待时机执行。在了解 事件循环（Event Loop）之前，我们先来熟悉一下执行栈和事件队列这两个概念。

执行栈

当我们调用一个方法的时候，js会生成一个与这个方法相对应的执行环境。 而当一系列方法被依次调用的时候，因为js是单线程的，同一时间只能执行一个方法，于是这些方法被排队在一个单独的地方。这个地方被称为执行栈。

事件队列

当我们发起异步请求后，主线程并不会一直等待其返回结果，而是会将这个事件挂起，继续执行执行栈中的其他任务。等异步任务返回结果后，该异步任务按照执行顺序，加入到与执行栈不同的另一个队列，这个队列被称为事件队列。

这里我们需要明确以下几个概念：

1. 在Node环境中javascript运行的线程是单线程的，事件循环的线程也是单线程的，但这两个不是一个线程。
2. 在事件队列中，任务又分为宏任务和微任务：
   宏任务：setTimeout，setInterval，I/O操作，setImmediate…
   微任务：process.nextTick(优先级最高)、promise.then、await…
3. 主线程会先将执行栈中的同步任务清空，当执行栈中的任务清空，主线程会先检查微任务队列中是否有任务，如果有，就将微任务队列中的任务依次执行，直到微任务队列为空，之后再检查宏任务队列中是否有任务，如果有，则每次取出第一个宏任务加入到执行栈中，之后再清空执行栈，检查微任务，以此循环……

我们再来举个简单的例子：

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。

总的概括为: 执行所有同步任务 -> 清空所有微任务 -> 执行一个宏任务 -> 清空所有微任务 -> 执行一个宏任务…清空所有微-> 执行一个宏…… 以此循环

事件循环流程解析

当 Node.js 启动后，它会初始化事件循环，处理已提供的输入脚本（或丢入 REPL，本文不涉及到），它可能会调用一些异步的 API、调度定时器，或者调用 process.nextTick()，然后开始处理事件循环。

下面的图表展示了事件循环操作顺序的简化概览。

注意：每个框被称为事件循环机制的一个阶段。

每个阶段都有一个 FIFO 队列来执行回调。虽然每个阶段都是特殊的，但通常情况下，当事件循环进入给定的阶段时，它将执行特定于该阶段的任何操作，然后执行该阶段队列中的回调，直到队列用尽或最大回调数已执行。当该队列已用尽或达到回调限制，事件循环将移动到下一阶段，等等。

由于这些操作中的任何一个都可能调度 更多的 操作和由内核排列在轮询阶段被处理的新事件， 且在处理轮询中的事件时，轮询事件可以排队。因此，长时间运行的回调可以允许轮询阶段运行长于计时器的阈值时间。有关详细信息，请参阅 计时器 和 轮询 部分。

注意： 在 Windows 和 Unix/Linux 实现之间存在细微的差异，但这对演示来说并不重要。最重要的部分在这里。实际上有七或八个步骤，但我们关心的是 Node.js 实际上使用以上的某些步骤。

阶段概述

• timers：本阶段执行已经被 setTimeout() 和 setInterval() 的调度回调函数。
• pending callbacks：执行延迟到下一个循环迭代的 I/O 回调。
• idle, prepare：仅系统内部使用。
• poll：检索新的 I/O 事件;执行与 I/O 相关的回调（几乎所有情况下，除了关闭的回调函数，那些由计时器和 setImmediate() 调度的之外），其余情况 node 将在适当的时候在此阻塞。
• check：setImmediate()回调函数在这里执行。
• close callbacks：一些关闭的回调函数，如：socket.on(‘close’, …)。

在每次运行的事件循环之间，Node.js 检查它是否在等待任何异步 I/O 或计时器，如果没有的话，则完全关闭。

通过上图我们总结一下:
1、事件循环一共有6个阶段，每个阶段都有自己特有的操作。
2、当事件循环进行到某个阶段时，会执行该阶段队列中的回调，直到队列空了或者达到了执行次数限制。
3、事件循环在进入下一个阶段前，会检查是否有microtask，如果有，全部执行、然后进入下一个阶段，循环往复。

我们重点看timers、poll、check这3个阶段就好。我们通过下面的例子来实践一下：

const fs = require('fs');
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');
});
setImmediate(() => {
    console.log('4');
})
//输出结果顺序是：1，3，2，4

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 执行不在 I/O 周期（即主模块）内的脚本，则执行两个计时器的顺序是非确定性的，因为它受进程性能的约束。

setTimeout(() => {
    console.log('setTimeout');
},0)
setImmediate(() => {
    console.log('setImmediate');
})

在node环境中，多次执行上面的代码，就会发现如下两种结果：
（1）先输出setTimeout，后输出setImmediate；
（2）先输出setImmediate，后输出setTimeout。

分析原因是原来事件循环每一次都有个时间间隔。这取决于当前 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 放入一个 I/O 循环内调用，setImmediate 总是被优先调用：

const 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事件循环的一些看法，涵盖的知识点比较多，我认为重点就在于要理解好每个循环阶段的工作，清楚的了解了事件循环的执行顺序和每一个阶段的特点，可以使我们对一段异步代码的执行顺序有一个清晰的认识。如有不对的地方欢迎各位大牛互相讨论学习。