浏览器和Node 中的Event Loop
前言
js与生俱来的就是单线程无阻塞的脚本语言。 作为单线程语言,js代码执行时都只有一个主线程执行任务。
无阻塞的实现依赖于我们要谈的事件循环。eventloop的规范是真的苦涩难懂,仅仅要理解的话,不推荐去硬啃。
进程与线程
一直在说js是单线程语言。那么什么是线程呢,对于大部分前端同学来说,可能并不是那么清晰。推荐阮大佬的这篇文章,形象生动
首先,计算机的核心是CPU,它承担了所有的计算任务。它就像一座工厂,时刻在运行。
进程
进程就好比工厂的车间,它代表CPU所能处理的单个任务。
任一时刻,CPU总是运行一个进程,其他进程处于非运行状态。
即资源分配的最小单位,拥有独立的堆栈空间和数据存储空间
线程
线程就好比车间里的工人。车间的空间是工人们共享的,这象征一个进程的内存空间是共享的,每个线程都可以使用这些共享内存。
即程序执行的最小单位,一个进程可以包括多个线程。
相对于进程来说,线程不涉及数据空间的操作,所以切换更高效,开销小。
js单线程的起源
显然多进程可以并行处理,提升cpu的利用率。
但是js初期是作为脚本出现的,其要与DOM进行交互,以完成对用户的展示。
如果多进程,同时操作DOM,那么后果就不可控了。
例如:对于同一个按钮,不同的进程赋予了不同的颜色,到底该怎么展示。
作为一个脚本语言,如果使用多线程+锁的话太多复杂了,所以js就是单线程了。
不过随着js的发展,承载的能力越来越多,局限于单线程使得js的效率等有所限制。
因此增加了web worker来执行非dom的操作。
不过该线程非主线程有一些限制、例如不能操作DOM等,也就是为了保证DOM操作的一致性,这里就先不关注了。
我们主要关注的还是非阻塞的能力基础,即事件循环。
浏览器中的事件循环
说道事件循环就要先说事件队列。
在主线程运行时,会产生堆(heap)和栈(stack)。
堆中存的是我们声明的object类型的数据,栈中存的是基本数据类型以及函数执行时的运行空间。
主线程从任务队列中读取事件,这个过程是循环不断的,所以这种运行机制即Event Loop。
对于同步代码,是直接执行的。 而执行异步方法时同样会加入事件队列中,但是异步事件是有差别的,差别在于执行的优先级不同。事件分类
因为异步任务之间并不相同,因此他们的执行优先级也有区别。不同的异步任务被分为两类:微任务(micro task)和宏任务(macro task)。
- 以下事件属于宏任务:
setTimeout, setInterval, setImmediate,I/O, UI rendering
- 以下事件属于微任务
Promise,Object.observe(已废弃),MutationObserver(html5新特性),process.nextTick
执行栈中的代码(同步任务),总是在读取"任务队列"(异步任务)之前执行
当前执行栈执行完毕时会立刻先处理所有微任务队列中的事件,然后再去宏任务队列中取出一个事件。同一次事件循环中,微任务永远在宏任务之前执行
对于不同类型的任务执行顺序如下:
- 同步代码执行
- event-loop start
- microTasks 队列开始清空(执行)
- 检查 Tasks 是否清空,有则跳到 4,无则跳到 6
- 从 Tasks 队列抽取一个任务,执行
- 检查 microTasks 是否清空,若有则跳到 2,无则跳到 3
- 结束 event-loop
大概流程图如下:
不如直接看个栗子:
setTimeout(function () {
console.log(1);
});
new Promise(function(resolve,reject){
console.log(2)
resolve(3)
}).then(function(val){
console.log(val);
})
// 2 3 1
- 区分事件类型:宏任务setTimeout,微任务.then
- 同步代码执行 输出2
- 微任务队列清空 输出 3
- 宏任务执行 输出 1
下面来个稍微复杂的:
setTimeout(()=>{
console.log('A');
},0);
var obj={
func:function () {
setTimeout(function () {
console.log('B')
},0);
return new Promise(function (resolve) {
console.log('C');
resolve();
})
}
};
obj.func().then(function () {
console.log('D')
});
console.log('E');
// c,e,d,b,a
大家可以结合例子自己试下。
node中的事件循环机制
在node中,事件循环表现出的状态与浏览器中大致相同。不同的是node中有一套自己的模型。
node中事件循环的实现是依靠的libuv引擎。
我们知道node选择chrome v8引擎作为js解释器,v8引擎将js代码分析后去调用对应的node api,
而这些api最后则由libuv引擎驱动,执行对应的任务,并把不同的事件放在不同的队列中等待主线程执行。
因此实际上node中的事件循环存在于libuv引擎中。
而node 事件分为下面几大阶段:
- timers: 这个阶段执行setTimeout()和setInterval()设定的回调。
- I/O callbacks: 执行几乎所有的回调,除了close回调,timer的回调,和setImmediate()的回调。
- idle, prepare: 仅内部使用。
- poll: 获取新的I/O事件;node会在适当条件下阻塞在这里,等待新的I/O。
- check: pool阶段之后,执行setImmediate()设定的回调。
- close callbacks: 执行比如socket.on('close', ...)的回调
poll阶段
值得额外关注的是poll阶段
该阶段有如下功能:
- 执行 timer 阶段到达时间上限的的任务。
- 执行 poll 阶段的任务队列。
如果进入 poll 阶段,并且没有 timer 阶段加入的任务,将会发生以下情况
- 如果 poll 队列不为空的话,会执行 poll 队列直到清空或者系统回调数达到上限
- 如果 poll 队列为空 如果设定了 setImmediate 回调,会直接跳到 check 阶段。 如果没有设定 setImmediate 回调,会阻塞住进程,并等待新的 poll 任务加入并立即执行。
process.nextTick()
nextTick 比较特殊,它有自己的队列,并且,独立于event loop。 它的执行也非常特殊,无论 event loop 处于何种阶段,都会在阶段结束的时候清空 nextTick 队列。
直接看例子吧:
process.nextTick
process.nextTick(function A() {
console.log(1);
process.nextTick(function B(){console.log(2);});
});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 0)
// 1
// 2
// TIMEOUT FIRED
大概顺序如下:
- 因为nextTick的特殊性,当前阶段执行完毕,就执行。所以直接,输出1 2
- 执行到timer 输出 TIMEOUT FIRED
setImmediate
setImmediate(function A() {
console.log(1);
setImmediate(function B(){console.log(2);});
});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 0);
这个结果不固定,同一台机器测试结果也有两种:
// TIMEOUT FIRED =>1 =>2
或者
// 1=>TIMEOUT FIRED=>2
- 事件队列进入timer,性能好的 小于1ms,则不执行回调继续往下。若此时大于1ms, 则输出 TIMEOUT FIRED 就不输出步骤3了。
- poll阶段任务为空,存在setImmediate 直接进入setImmediate 输出1
- 然后再次到达timer 输出 TIMEOUT FIRED
- 再次进入check 阶段 输出 2
原因在于setTimeout 0 node 中至少为1ms,也就是取决于机器执行至timer时是否到了可执行的时机。
做个对比就比较清楚了:
setImmediate(function A() {
console.log(1);
setImmediate(function B(){console.log(2);});
});
setImmediate(function B(){console.log(4);});
setTimeout(function timeout() {
console.log('TIMEOUT FIRED');
}, 20);
// 1=>2=>TIMEOUT FIRED
此时间隔时间较长,timer阶段最后才会执行,所以会先执行两次check,出处1,2
下面再看个例子
poll阶段任务队列
var fs = require('fs')
fs.readFile('./yarn.lock', () => {
setImmediate(() => {
console.log('1')
setImmediate(() => {
console.log('2')
})
})
setTimeout(() => {
console.log('TIMEOUT FIRED')
}, 0)
})
// 结果确定:
// 输出始终为1=>TIMEOUT FIRED=>2
- 读取文件,回调进入poll阶段
- 当前无任务队列,直接check 输出1 将setImmediate2加入事件队列
- 接着timer阶段,输出TIMEOUT FIRED
- 再次check阶段,输出2
小结
浏览器的事件循环
浏览器比较清晰一些,就是固定的流程,当前宏任务结束,就是执行所有微任务(不一定是全部,可能基于系统能力,会有所剩下),然后再下一个宏任务,微任务这样交替进行。
node中的事件循环
主要是把握不同阶段和特殊情况的处理,特别是poll阶段和 process.nextTick任务。
结束语
参考文章:
https://zhuanlan.zhihu.com/p/47152694
https://html.spec.whatwg.org/multipage/webappapis.html#event-loop
http://www.ruanyifeng.com/blog/2014/10/event-loop.html
https://hackernoon.com/understanding-js-the-event-loop-959beae3ac40
https://juejin.im/post/5bac87b6f265da0a906f78d8
感谢上述参考文章,关于事件循环这里就总结完毕了,作为自己的一个学习心得。希望能帮助到有需求的同学,一起进步。