深入浅出NodeJS事件循环

1,093 阅读9分钟

前言

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

正确的答案为 146792583\color{red}{1、4、6、7、9、2、5、8、3} (注: 我们的运行环境是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中事件循环的具体流程:

event_loop

通过上图我们总结一下: 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事件循环的一些看法,涵盖的知识点比较多,我认为重点就在于要理解好每个循环阶段的工作,清楚的了解了事件循环的执行顺序和每一个阶段的特点,可以使我们对一段异步代码的执行顺序有一个清晰的认识。如有不对的地方欢迎各位大虾互相讨论学习。 最后的最后,我们再回头看一下开篇的题目,相信各位仁兄一定胸有成竹了吧。