13518219792

建站动态

根据您的个性需求进行定制 先人一步 抢占小程序红利时代

详解JavaScript运行机制(EventLoop)

【稿件】

前言

在浏览器中,每个渲染进程都有一个主线程,主线程非常繁忙,既要处理DOM,又要计算样式,还要处理布局,同时还需要处理JavaScript任务以及各种输入事件。此时我们就需要一个系统来统筹调度这么多不同类型的任务在主线程中有条不紊地执行,而这个统筹调度系统就是本文要介绍的事件循环系统(Event Loop)。

读完本文,希望你能明白:

一、进程与线程

1.概念

我们经常说JavaScript是单线程执行的,那到底什么是线程?什么是进程?

一个进程就是一个程序的运行实例。详细解释就是,启动一个程序的时候,操作系统会为该程序创建一块内存,用来存放代码、运行中的数据和一个执行任务的主线程,我们把这样的一个运行环境叫进程。

而线程是操作系统能够进行运算调度的最小单位。线程是不能单独存在的,它是由进程来启动和管理的,在进程中使用多线程并行处理能提升运算效率。

我们通过以下这张图来加深对两者的理解:

2.多进程与多线程

以最新的 Chrome 浏览器为例,我打开掘金编辑文章页面时,出现以下五个进程:1个网络进程、1个浏览器进程、1个GPU进程以及1个渲染进程,共4个;如果打开的页面有运行插件的话,还需要再加上1个插件进程(下图有番茄闹钟插件)。

二、最新的 Chrome 进程架构

最新的Chrome浏览器包括:1个浏览器(Browser)主进程、1个GPU进程、1个网络(NetWork)进程、多个渲染进程和多个插件进程。

接下来我们介绍下这些进程的功能:

页面中的大部分任务都是在渲染进程的主线程上执行,这些任务包括了:

那么,如何协调这些任务有条不紊地在主线程上执行呢? 这就需要事件循环系统(Event Loop)

三、浏览器中的 Event Loop

1.什么是Event Loop

通过使用消息队列,我们实现了线程之间的消息通信。在Chrome中,跨进程之间的任务也是频繁发生的,那么如何处理其他进程发送过来的任务?可以参考下图(来源极客时间):

消息队列是一种数据结构,可以存放要执行的任务。它符合队列“先进先出”的特点,也就是说要添加任务的话,添加到队列的尾部;要取出任务的话,从队列头部去取。

从图中可以看出,渲染进程专门有一个IO线程用来接收其他进程传进来的消息,接收到消息之后,会将这些消息组装成任务发送给渲染主线程。主线程从"消息队列"中读取事件,这个过程是循环不断的,所以整个的这种运行机制又称为Event Loop(事件循环)。

2.同步任务和异步任务

浏览器端常见的宏任务包括:setTimeout、setInterval、script(整体代码)、 I/O 操作、UI 渲染等;

浏览器端常见的微任务包括:new Promise().then(回调)、MutationObserver(html5新特性) 等。

3.Event Loop 过程解析

一个完整浏览器端的 Event Loop 过程,可以概括为以下阶段:

我们总结一下,每一次循环都是一个这样的过程:

当某个宏任务执行完后,会查看是否有微任务队列。如果有,先执行微任务队列中的所有任务,如果没有,会读取宏任务队列中排在最前的任务,执行宏任务的过程中,遇到微任务,依次加入微任务队列。栈空后,再次读取微任务队列里的任务,依次类推。

接下来我们看道例子来介绍上面流程:

 
 
 
 
  1. Promise.resolve().then(()=>{ 
  2. console.log('Promise1')   
  3. setTimeout(()=>{ 
  4.   console.log('setTimeout2') 
  5. },0) 
  6. }) 
  7. setTimeout(()=>{ 
  8. console.log('setTimeout1') 
  9. Promise.resolve().then(()=>{ 
  10.   console.log('Promise2')     
  11. }) 
  12. },0) 

最后输出结果是Promise1,setTimeout1,Promise2,setTimeout2

四、Node 中的 Event Loop

1.Node简介

Node 环境下的 Event Loop 与浏览器环境下的 Event Loop并不相同。Node.js 采用 V8 作为js的解析引擎,而I/O处理方面使用了自己设计的libuv,libuv是一个基于事件驱动的跨平台抽象层,封装了不同操作系统一些底层特性,对外提供统一的API,事件循环机制也是它里面的实现(下文会详细介绍)。注:本文中所介绍Node 环境中的 Event Loop,是基于node10及其之前版本。

Node.js的运行机制如下:

2.六个阶段

其中libuv引擎中的事件循环分为 6 个阶段,它们会按照顺序反复运行。每当进入某一个阶段的时候,都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值,就会进入下一阶段。

从上图中,大致看出node中的事件循环的顺序:

外部输入数据-->轮询阶段(poll)-->检查阶段(check)-->关闭事件回调阶段(close callback)-->定时器检测阶段(timer)-->I/O事件回调阶段(I/O callbacks)-->闲置阶段(idle, prepare)-->轮询阶段(按照该顺序反复运行)...

注意:上面六个阶段都不包括 process.nextTick()(下文会介绍)

接下去我们详细介绍timerspollcheck这3个阶段,因为日常开发中的绝大部分异步任务都是在这3个阶段处理的。

(1) timer

timers 阶段会执行 setTimeout 和 setInterval 回调,并且是由 poll 阶段控制的。 同样,在 Node 中定时器指定的时间也不是准确时间,只能是尽快执行

(2) poll

poll 是一个至关重要的阶段,这一阶段中,系统会做两件事情:

1.回到 timer 阶段执行回调

2.执行 I/O 回调

并且在进入该阶段时如果没有设定了 timer 的话,会发生以下两件事情:

当然设定了 timer 的话且 poll 队列为空,则会判断是否有 timer 超时,如果有的话会回到 timer 阶段执行回调。

(3) check阶段

setImmediate()的回调会被加入check队列中,从event loop的阶段图可以知道,check阶段的执行顺序在poll阶段之后。 我们先来看个例子:

 
 
 
 
  1. console.log('start') 
  2. setTimeout(() => { 
  3. console.log('timer1') 
  4. Promise.resolve().then(function() { 
  5.   console.log('promise1') 
  6. }) 
  7. }, 0) 
  8. setTimeout(() => { 
  9. console.log('timer2') 
  10. Promise.resolve().then(function() { 
  11.   console.log('promise2') 
  12. }) 
  13. }, 0) 
  14. Promise.resolve().then(function() { 
  15. console.log('promise3') 
  16. }) 
  17. console.log('end') 
  18. //start=>end=>promise3=>timer1=>timer2=>promise1=>promise2 

3.Micro-Task 与 Macro-Task

Node端事件循环中的异步队列也是分为macro(宏任务)队列和 micro(微任务)队列。

4.注意点

(1) setTimeout 和 setImmediate

二者非常相似,区别主要在于调用时机不同。

 
 
 
 
  1. setTimeout(function timeout () { 
  2. console.log('timeout'); 
  3. },0); 
  4. setImmediate(function immediate () { 
  5. console.log('immediate'); 
  6. }); 

但当二者在异步i/o callback内部调用时,总是先执行setImmediate,再执行setTimeout

 
 
 
 
  1. const fs = require('fs') 
  2. fs.readFile(__filename, () => { 
  3.   setTimeout(() => { 
  4.       console.log('timeout'); 
  5.   }, 0) 
  6.   setImmediate(() => { 
  7.       console.log('immediate') 
  8.   }) 
  9. }) 
  10. // immediate 
  11. // timeout 

在上述代码中,setImmediate 永远先执行。因为两个代码写在 IO 回调中,IO 回调是在 poll 阶段执行,当回调执行完毕后队列为空,发现存在 setImmediate 回调,所以就直接跳转到 check 阶段去执行回调了。

(2) process.nextTick

这个函数其实是独立于 Event Loop 之外的,它有一个自己的队列,当每个阶段完成后,如果存在 nextTick 队列,就会清空队列中的所有回调函数,并且优先于其他 microtask 执行。

 
 
 
 
  1. setTimeout(() => { 
  2. console.log('timer1') 
  3. Promise.resolve().then(function() { 
  4.   console.log('promise1') 
  5. }) 
  6. }, 0) 
  7. process.nextTick(() => { 
  8. console.log('nextTick') 
  9. process.nextTick(() => { 
  10.   console.log('nextTick') 
  11.   process.nextTick(() => { 
  12.     console.log('nextTick') 
  13.     process.nextTick(() => { 
  14.       console.log('nextTick') 
  15.     }) 
  16.   }) 
  17. }) 
  18. }) 
  19. // nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1 

五、Node与浏览器的 Event Loop 差异

浏览器环境下,microtask的任务队列是每个macrotask执行完之后执行。而在Node.js中,microtask会在事件循环的各个阶段之间执行,也就是一个阶段执行完毕,就会去执行microtask队列的任务

接下我们通过一个例子来说明两者区别:

 
 
 
 
  1. setTimeout(()=>{ 
  2.   console.log('timer1') 
  3.   Promise.resolve().then(function() { 
  4.       console.log('promise1') 
  5.   }) 
  6. }, 0) 
  7. setTimeout(()=>{ 
  8.   console.log('timer2') 
  9.   Promise.resolve().then(function() { 
  10.       console.log('promise2') 
  11.   }) 
  12. }, 0) 

浏览器端运行结果:timer1=>promise1=>timer2=>promise2

浏览器端的处理过程如下:

Node端运行结果:

要看第一个定时器执行完,第二个定时器是否在完成队列中。

1.全局脚本(main())执行,将2个timer依次放入timer队列,main()执行完毕,调用栈空闲,任务队列开始执行;

2.首先进入timers阶段,执行timer1的回调函数,打印timer1,并将promise1.then回调放入microtask队列,同样的步骤执行timer2,打印timer2;

3.至此,timer阶段执行结束,event loop进入下一个阶段之前,执行microtask队列的所有任务,依次打印promise1、promise2

Node端的处理过程如下:

六、总结

浏览器和Node 环境下Event Loop有所区别,主要体现在微任务队列的执行时机不同

参考文章与资料

作者介绍

浪里行舟:硕士研究生,专注于前端。个人公众号:「前端工匠」,致力于打造适合初中级工程师能够快速吸收的一系列优质文章!

【原创稿件,合作站点转载请注明原文作者和出处为.com】


网站栏目:详解JavaScript运行机制(EventLoop)
网页URL:http://cdbrznjsb.com/article/djspihh.html

其他资讯

让你的专属顾问为你服务