此篇文章旨在帮助理解浏览器和Node.js的事件循环机制,如有不足或错误之处,望指出。
大家好鸭,博主是一个飞向前端开发的小泡泡!
作为一个前端的开发人员,经常会与浏览器以及Node.js打交道,那么,对于事件循环机制,相信大家都不会太过陌生,但是一旦遇到了这方面的问题,有些也只是一知半解,甚至无从下手。博主看过了许多相关的公众号和博客,发现有些讲的并不是那么完善,就将这些总结在一起吧,更有利于系统性的学习。
我们知道,javascript是单线程的,在同一个时间内只能执行一个任务,那他是如何做到异步回调的呢?我会在后面给出答案,首先我们从进程和线程这两方面入手,循序渐进。
CPU?进程?线程?
我们经常会听到CPU、线程、进程等名词,以下做一个比较形象的比喻吧。
CPU
计算机的核心是CPU,就像是一个工厂,所有的任务执行都在这里,并且是时刻运行的。
进程
进程,代表CPU所能处理的单个任务,类似工厂里的车间,由于资源有限,工厂只能将其分配给一个车间,其他车间就必须停止工作,也就是说单个CPU只能运行一个进程(任务),通过时间片轮转调度算法,可以实现CPU运行多个进程。
线程
线程,类似车间里的每一个工人,属于同一个车间的工人共享同一个资源,完成同一个任务。一个进程可以包含多个线程,多个线程共享同一个资源。
总结
- 进程是CPU资源分配的最小单位。
- 线程是CPU资源调度的最小单位,是建立在进程的基础上的一次程序运行单位。
- 一个进程可以包含多个线程,多个线程共享进程资源。
- 单线程和多线程都是在同一个进程之内。
浏览器是多进程还是单进程?
对于每一个计算机,一个应用程序就代表了一个进程,每个应用程序的功能模块又是由不同子进程实现的,那么这个应用程序就是“多进程”的。那么,浏览器究竟属于单进程还是多进程呢?其实很简单,只需要打开任务管理器,在浏览器打开多个tab页,便会在任务管理器显示出多个子进程,所以浏览器是多进程的。
浏览器包含了哪些进程?
- 主进程
- 第三方插件进程
- GPU进程(3D绘制)
- 渲染进程(浏览器内核)
其中,我们前端经常接触到的是渲染进程,也就是浏览器内核。它负责页面的渲染,脚本执行,事件处理等,上面的每个tab页就包含一个渲染进程。
渲染进程(浏览器内核)
前面提起过,一个进程可以包含多个线程,那么渲染进程也不例外,它包含了以下几个线程。
-
GUI渲染线程
1.负责页面的布局,绘制以及渲染。
2.在页面发生回流(重排)以及重绘时就会执行该线程。
3.与JS引擎线程互斥,避免影响绘制效果。 -
JS引擎线程
1.负责解析并执行相关的js脚本。
2.只存在一个JS引擎线程(单线程)。
3.与GUI渲染线程互斥,避免影响绘制效果。 -
事件触发线程
1.用于控制事件循环。
2.当满足相应的触发条件时,会执行相应的事件,也可能会产生新的线程。
3.将回调放入任务队列,管理任务队列。 -
定时器触发线程
1.setTimeout、setInterval所在线程。
2.执行相应的定时任务。
3.计时完毕后将相关的回调函数交由事件触发线程处理。 -
异步HTTP请求线程
1.用于处理Ajax请求。
2.请求完毕后若有回调任务,将相关的回调函数交由事件触发线程处理。
结合图一起来理解下吧~
Tip:为什么GUI渲染线程会和JS引擎线程互斥呢?
由于JS也是可以对DOM进行操作的,若同时对页面元素进行修改,重新渲染页面后可能会出现不可预期的结果,所以两者不可同时运行。
浏览器的事件循环机制(Event Loop)
在对浏览器的进程、线程有了基本的了解之后,我们开始讲述下关于浏览器里的事件循环。
我们知道,JS任务分为同步任务以及异步任务,同步任务会在执行栈中顺序执行,而异步任务则会放到任务队列里,等待JS引擎线程空闲之后才会将这些异步任务依次推入到执行栈中,供JS引擎线程执行。如下图:
如此执行就是我们常常听到的事件循环,也就是javascript实现异步的核心所在。
事件循环如何处理定时任务以及网络请求?
对于定时任务:当JS引擎线程执行到定时任务代码,例如setTimeout、setInterval,JS引擎线程会通知定时器触发线程,间隔一段时间触发一个回调函数,定时器触发线程接收消息后,进行计时,计时结束后,会将相应的回调函数交由事件触发线程,再将其放入任务队列中。
对于网络请求:当JS引擎线程执行到网络请求代码,例如ajax、fetch,JS引擎线程会通知异步HTTP请求线程,向服务器发送请求,请求结束后,若有回调函数,则会将相应的回调函数交由事件触发线程,再将其放入任务队列中。
用段代码解释一下~
// 同步任务
console.log(1)
// 同步任务
// 通知定时器线程 1s 后将回调交由事件触发线程处理
// 1s 后事件触发线程将回调加入到任务队列中
setTimeout(() => {
console.log(2)
}, 0)
// 同步任务
// 通知异步HTTP请求线程发送网络请求,请求完成后将回调交由事件触发线程处理
// 请求完成后事件触发线程将回调加入到任务队列中
$.get('www.xxxxxxxxx.com', () => {
console.log(3)
})
// 同步任务
console.log(4)
// 所有同步任务执行完后
// 询问事件触发线程在任务队列中是否有需要执行的回调函数
// 如果没有,一直询问,直到有为止
// 如果有,将回调事件加入执行栈中,开始执行回调代码
打印出的顺序应为1-4-2-3
关于宏任务和微任务
我们了解了执行栈、任务队列之后,再来认识下什么是事件循环中的宏任务(macrotask)和微任务(microtask)。
- 宏任务:我们可以把每次在执行栈里执行的一系列代码看成一个宏任务(包括每次从事件队列里将一个回调函数放入执行栈执行)。宏任务可以包含执行整体的script、事件回调、XHR回调、定时器(setTimeout、setInterval、setImmediate)、IO操作、UI render。
Tip:由于JS引擎线程和GUI渲染线程是互斥的,所以为了保证有效的进行渲染,在每次宏任务执行之后,下一次宏任务执行之前,GUI渲染线程都会执行一次,渲染页面。
- 微任务:微任务可以看做宏任务执行完毕后立刻执行的一系列任务,它在GUI渲染线程执行之前执行,在每一次宏任务执行完毕后,必须执行完所有微任务才能进入下一阶段。微任务可以包含Promise回调、MutationObserver、process.nextTick、Object.observe等。
Tip:setImmediate和process.nextTick是Node.js的实现,后面讲到了会做出详解。
- 整体流程为: 宏任务 => 微任务 => 渲染 => 宏任务 => .......
图解如下:
来段代码感受一下吧,举一个小栗子!
console.log('start')
setTimeout(function() {
console.log('setTimeout')
}, 0)
Promise.resolve().then(function() {
console.log('promise1')
}).then(function() {
console.log('promise2')
})
console.log('end')
以上输出结果会是什么呢?我们来一步一步分析
- 首先,系统将主代码块(整体的script)放入执行栈中,开始执行第一次宏任务。
- JS引擎线程顺序执行同步代码,先输出start。
- 遇到setTimeout,通知定时器触发线程,经过一段时间将回调交由事件触发线程,事件触发线程将回调函数放入任务队列的宏任务队列中。
- 遇到Promise回调,执行同步代码,然后将回调函数通过事件触发线程放入任务队列的微任务队列中。
- 输出end,第一次宏任务结束。
- 紧接着执行微任务,推出微任务列表中的任务放入执行栈中执行,输出promise1,由于后面又接着一个Promise回调,再继续将该回调放入微任务队列,再次推出微任务列表中的任务放入执行栈中执行输出promise2(因为必须执行完该次宏任务生成的所有微任务才能继续向下执行)。
- 渲染页面(GUI渲染线程接管,不一定执行)。
- 此时执行栈为空,系统从任务队列的宏任务队列中推出一个宏任务到执行栈中执行,执行第二次宏任务,输出setTimeout。
因此执行顺序为:start => end => promise1 => promise2 => setTimeout
我们利用一张动图来展现一下~
完整的渲染进程如下
总结:浏览器的事件循环
- 执行一个宏任务(执行栈为空则从任务队列的宏任务队列中获取)。
- 执行过程中如果遇到微任务,就将它添加到任务队列的微任务队列中。
- 宏任务执行完毕后,立即依次执行当前微任务队列中的所有微任务。
- 当前宏任务执行完毕,GUI线程接管渲染。
- 渲染完毕后,JS线程继续接管,开始下一个宏任务。
Node.js的事件循环机制(Event Loop)
在浏览器存在着事件循环,Node.js也同样存在事件循环,那么两个事件循环有什么区别呢?我们先看一下下面的代码输出了些什么吧。
setTimeout(()=>{
console.log(1)
Promise.resolve().then(function() {
console.log(2)
})
}, 0)
setTimeout(()=>{
console.log(3)
Promise.resolve().then(function() {
console.log(4)
})
}, 0)
在浏览器上,我们输出的结果为1 => 2 => 3 => 4
而在Node.js中,我们输出的结果为1 => 3 => 2 => 4
诶?我们发现,两者的输出结果不尽相同,可见还是存在差异的。
Node.js的事件循环机制的六个阶段
与浏览器不同的是,浏览器的Event Loop是HTML5中定义的规范,而Node.js采用V8引擎,其中的Event Loop是依赖libuv库实现的,libuv是一个基于事件驱动的跨平台抽象层,封装了许多实用的API,事件循环的六个阶段就是在这里面编写的。
Node.js每次事件循环机制分为以下六个阶段:
- timers 阶段:这个阶段检查是否有到期的timer(setTimeout、setInterval),并执行相应的回调函数。
- I/O callbacks 阶段:执行延迟到下一个循环迭代的 I/O 回调,即普通的回调。
- idle, prepare 阶段:仅系统内部使用。
- poll 阶段:检索新的 I/O 事件;执行与 I/O 相关的回调(几乎所有情况下,除了关闭的回调函数,它们由计时器和 setImmediate() 排定的之外),其余情况 node 将在此处阻塞。
- check 阶段:执行setImmediate的回调函数。
- close callbacks 阶段:一些准备关闭的回调函数,如:socket.on('close', ...)
对于我们理解事件循环,只需要关注timers、poll、check这3个阶段即可,在我们进行开发的过程中大部分的异步任务都在这些阶段进行的。
timers 阶段
timers是事件循环的第一个阶段,这个阶段会检查是否有到期的timer(setTimeout、setInterval),有则将回调函数放入timers的任务队列里等待执行。Node对时间的到期检查并不是十分精确,并不能保证timer在预设时间到了就会立即执行。例如以下代码:
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
在不同环境下和情况下结果可能是不同的,有些是timeout => immediate,有些是immediate => timeout,这是因为计时会受进程性能的约束(受到计算机上运行的其它应用程序的影响),从而造成setTimeout做不到0毫秒,最少也需要1毫秒,根据官方文档,第二个参数的取值范围在1毫秒到2147483647毫秒之间。也就是说,setTimeout(f, 0)等同于setTimeout(f, 1)。
但是,如果将以上代码放在一个I/O操作的回调函数中,则一定先输出immediate,因为poll阶段后面就是check阶段。
const fs = require('fs');
fs.readFile(__filename, () => {
setTimeout(() => {
console.log('timeout');
}, 0);
setImmediate(() => {
console.log('immediate');
});
});
// 输出immediate => timeout
poll 阶段
poll阶段是事件循环的轮询阶段,主要做两件事:
- 执行poll队列中的回调任务。
- poll队列为空时,若有已超时的timer,则执行它的回调函数。
到了该阶段,会执行poll队列里的回调任务,当任务执行完毕,队列为空或上限时,回去检查脚本中是否有预设的setImmediate。若有则进入check阶段,执行check的任务队列;若没有则阻塞在该阶段。但是事件循环并不会一直保持这种阻塞状态,它会去检查是否有已过期的timer。如果有,则事件循环将绕回timers阶段以执行这些计时器的回调。
check阶段
这个阶段会执行check队列中的setImmediate的回调任务。
Tip: Node.js事件循环的每个阶段都有一个任务队列。
就之前的代码来一步一步解析下吧!
setTimeout(()=>{
console.log(1)
Promise.resolve().then(function() {
console.log(2)
})
}, 0)
setTimeout(()=>{
console.log(3)
Promise.resolve().then(function() {
console.log(4)
})
}, 0)
- 首先,系统将主代码块压入执行栈中执行,将两个timer放入timers阶段的任务队列中。
- 此时执行栈为空,任务队列开始执行。
- 先进入timers阶段,执行第一个回调函数输出1,然后将Promise回调放入到微任务队列(microtask queue)中。
- 执行timers阶段的下一个回调函数输出3,然后将Promise回调放入到微任务队列(microtask queue)中,timers阶段结束。
- 在事件循环的每一个阶段结束后,新的阶段开始前都会执行microtask queue中的所有微任务,所以依次执行输出2,4。
- 最后结果为1 => 3 => 2 => 4。
我们利用一张动图来展现一下~
Tip:除了microtask队列之外,还存在着nextTick队列,会在microtask执行之前执行。
总结:Node.js的事件循环
- Node.js的事件循环分为六个阶段。
- 浏览器和Node.js的事件循环的微任务(microtask)队列执行的时机不同。浏览器中是在每一次宏任务执行结束之后立即执行;Node中是在事件循环的每一个阶段结束后执行。
- 递归的调用process.nextTick()会导致I/O starving,官方推荐使用setImmediate()。
- 在每个阶段执行完毕后都会执行microtask queue以及nextTick queue。即同步任务一旦执行完成,就开始执行它们。
- 如果在 timers 阶段执行时创建了setImmediate 则会在此轮循环的 check 阶段执行,如果在 timers 阶段创建了setTimeout,由于 timers 已取出完毕,则会进入下轮循环,check 阶段创建 timers 任务同理。
- 在执行事件循环之前,会做以下几件事:
1.同步任务
2.发出异步请求
3.规划定时器生效的时间
4.执行process.nextTick()和promise回调
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/Sivak_/article/details/102068644