乐趣区

关于javascript:浏览器与Node的事件循环Event-Loop有何区别

前言

本文咱们将会介绍 JS 实现异步的原理,并且理解了在浏览器和 Node 中 Event Loop 其实是不雷同的。

一、线程与过程

1. 概念

咱们常常说 JS 是单线程执行的,指的是一个过程里只有一个主线程,那到底什么是线程?什么是过程?

官网的说法是:过程是 CPU 资源分配的最小单位;线程是 CPU 调度的最小单位。这两句话并不好了解,咱们先来看张图:

  • 过程好比图中的工厂,有独自的专属本人的工厂资源。
  • 线程好比图中的工人,多个工人在一个工厂中合作工作,工厂与工人是 1:n 的关系。也就是说 一个过程由一个或多个线程组成,线程是一个过程中代码的不同执行路线
  • 工厂的空间是工人们共享的,这象征 一个过程的内存空间是共享的,每个线程都可用这些共享内存
  • 多个工厂之间独立存在。

2. 多过程与多线程

  • 多过程:在同一个工夫里,同一个计算机系统中如果容许两个或两个以上的过程处于运行状态。多过程带来的益处是显著的,比方你能够听歌的同时,关上编辑器敲代码,编辑器和听歌软件的过程之间丝毫不会互相烦扰。
  • 多线程:程序中蕴含多个执行流,即在一个程序中能够同时运行多个不同的线程来执行不同的工作,也就是说容许单个程序创立多个并行执行的线程来实现各自的工作。

以 Chrome 浏览器中为例,当你关上一个 Tab 页时,其实就是创立了一个过程,一个过程中能够有多个线程(下文会具体介绍),比方渲染线程、JS 引擎线程、HTTP 申请线程等等。当你发动一个申请时,其实就是创立了一个线程,当申请完结后,该线程可能就会被销毁。

二、浏览器内核

简略来说浏览器内核是通过获得页面内容、整顿信息(利用 CSS)、计算和组合最终输入可视化的图像后果,通常也被称为渲染引擎。

浏览器内核是多线程,在内核管制下各线程相互配合以放弃同步,一个浏览器通常由以下常驻线程组成:

  • GUI 渲染线程
  • JavaScript 引擎线程
  • 定时触发器线程
  • 事件触发线程
  • 异步 http 申请线程

1.GUI 渲染线程

  • 次要负责页面的渲染,解析 HTML、CSS,构建 DOM 树,布局和绘制等。
  • 当界面须要重绘或者因为某种操作引发回流时,将执行该线程。
  • 该线程与 JS 引擎线程互斥,当执行 JS 引擎线程时,GUI 渲染会被挂起,当工作队列闲暇时,主线程才会去执行 GUI 渲染。

2.JS 引擎线程

  • 该线程当然是次要负责解决 JavaScript 脚本,执行代码。
  • 也是次要负责执行筹备好待执行的事件,即定时器计数完结,或者异步申请胜利并正确返回时,将顺次进入工作队列,期待 JS 引擎线程的执行。
  • 当然,该线程与 GUI 渲染线程互斥,当 JS 引擎线程执行 JavaScript 脚本工夫过长,将导致页面渲染的阻塞。

3. 定时器触发线程

  • 负责执行异步定时器一类的函数的线程,如:setTimeout,setInterval。
  • 主线程顺次执行代码时,遇到定时器,会将定时器交给该线程解决,当计数结束后,事件触发线程会将计数结束后的事件退出到工作队列的尾部,期待 JS 引擎线程执行。

4. 事件触发线程

  • 次要负责将筹备好的事件交给 JS 引擎线程执行。

比方 setTimeout 定时器计数完结,ajax 等异步申请胜利并触发回调函数,或者用户触发点击事件时,该线程会将整装待发的事件顺次退出到工作队列的队尾,期待 JS 引擎线程的执行。

5. 异步 http 申请线程

  • 负责执行异步申请一类的函数的线程,如:Promise,axios,ajax 等。
  • 主线程顺次执行代码时,遇到异步申请,会将函数交给该线程解决,当监听到状态码变更,如果有回调函数,事件触发线程会将回调函数退出到工作队列的尾部,期待 JS 引擎线程执行。

三、浏览器中的 Event Loop

1.Micro-Task 与 Macro-Task

浏览器端事件循环中的异步队列有两种:macro(宏工作)队列和 micro(微工作)队列。宏工作队列能够有多个,微工作队列只有一个

  • 常见的 macro-task 比方:setTimeoutsetIntervalscript(整体代码)I/O 操作、UI 渲染等。
  • 常见的 micro-task 比方: new Promise().then(回调)、MutationObserver(html5 新个性) 等。

2.Event Loop 过程解析

一个残缺的 Event Loop 过程,能够概括为以下阶段:

  • 一开始执行栈空, 咱们能够把 执行栈认为是一个存储函数调用的栈构造,遵循先进后出的准则。micro 队列空,macro 队列里有且只有一个 script 脚本(整体代码)。
  • 全局上下文(script 标签)被推入执行栈,同步代码执行。在执行的过程中,会判断是同步工作还是异步工作,通过对一些接口的调用,能够产生新的 macro-task 与 micro-task,它们会别离被推入各自的工作队列里。同步代码执行完了,script 脚本会被移出 macro 队列,这个过程实质上是队列的 macro-task 的执行和出队的过程。
  • 上一步咱们出队的是一个 macro-task,这一步咱们解决的是 micro-task。但须要留神的是:当 macro-task 出队时,工作是 一个一个 执行的;而 micro-task 出队时,工作是 一队一队 执行的。因而,咱们解决 micro 队列这一步,会一一执行队列中的工作并把它出队,直到队列被清空。
  • 执行渲染操作,更新界面
  • 查看是否存在 Web worker 工作,如果有,则对其进行解决
  • 上述过程周而复始,直到两个队列都清空

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

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

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

Promise.resolve().then(()=>{console.log('Promise1')  
  setTimeout(()=>{console.log('setTimeout2')
  },0)
})
setTimeout(()=>{console.log('setTimeout1')
  Promise.resolve().then(()=>{console.log('Promise2')    
  })
},0) 

最初输入后果是 Promise1,setTimeout1,Promise2,setTimeout2

  • 一开始执行栈的同步工作(这属于宏工作)执行结束,会去查看是否有微工作队列,上题中存在(有且只有一个),而后执行微工作队列中的所有工作输入 Promise1,同时会生成一个宏工作 setTimeout2
  • 而后去查看宏工作队列,宏工作 setTimeout1 在 setTimeout2 之前,先执行宏工作 setTimeout1,输入 setTimeout1
  • 在执行宏工作 setTimeout1 时会生成微工作 Promise2,放入微工作队列中,接着先去清空微工作队列中的所有工作,输入 Promise2
  • 清空完微工作队列中的所有工作后,就又会去宏工作队列取一个,这回执行的是 setTimeout2

四、Node 中的 Event Loop

1.Node 简介

Node 中的 Event Loop 和浏览器中的是齐全不雷同的货色。Node.js 采纳 V8 作为 js 的解析引擎,而 I / O 解决方面应用了本人设计的 libuv,libuv 是一个基于事件驱动的跨平台形象层,封装了不同操作系统一些底层个性,对外提供对立的 API,事件循环机制也是它外面的实现(下文会具体介绍)。

Node.js 的运行机制如下:

  • V8 引擎解析 JavaScript 脚本。
  • 解析后的代码,调用 Node API。
  • libuv 库负责 Node API 的执行。它将不同的任务分配给不同的线程,造成一个 Event Loop(事件循环),以异步的形式将工作的执行后果返回给 V8 引擎。
  • V8 引擎再将后果返回给用户。

2. 六个阶段

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

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

内部输出数据 –> 轮询阶段(poll)–> 查看阶段(check)–> 敞开事件回调阶段(close callback)–> 定时器检测阶段(timer)–>I/ O 事件回调阶段(I/O callbacks)–> 闲置阶段(idle, prepare)–> 轮询阶段(依照该程序重复运行)…

  • timers 阶段:这个阶段执行 timer(setTimeout、setInterval) 的回调
  • I/O callbacks 阶段:解决一些上一轮循环中的多数未执行的 I/O 回调
  • idle, prepare 阶段:仅 node 外部应用
  • poll 阶段:获取新的 I / O 事件, 适当的条件下 node 将阻塞在这里
  • check 阶段:执行 setImmediate() 的回调
  • close callbacks 阶段:执行 socket 的 close 事件回调

留神:下面六个阶段都不包含 process.nextTick()(下文会介绍)

接下去咱们具体介绍 timerspollcheck 这 3 个阶段,因为日常开发中的绝大部分异步工作都是在这 3 个阶段解决的。

(1) timer

timers 阶段会执行 setTimeoutsetInterval 回调,并且是由 poll 阶段管制的。
同样,在 Node 中定时器指定的工夫也不是精确工夫,只能是尽快执行

(2) poll

poll 是一个至关重要的阶段,这一阶段中,零碎会做两件事件

1. 回到 timer 阶段执行回调

2. 执行 I/O 回调

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

  • 如果 poll 队列不为空,会遍历回调队列并同步执行,直到队列为空或者达到零碎限度
  • 如果 poll 队列为空时,会有两件事产生

    • 如果有 setImmediate 回调须要执行,poll 阶段会进行并且进入到 check 阶段执行回调
    • 如果没有setImmediate 回调须要执行,会期待回调被退出到队列中并立刻执行回调,这里同样会有个超时工夫设置避免始终期待上来

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

(3) check 阶段

setImmediate()的回调会被退出 check 队列中,从 event loop 的阶段图能够晓得,check 阶段的执行程序在 poll 阶段之后。
咱们先来看个例子:

console.log('start')
setTimeout(() => {console.log('timer1')
  Promise.resolve().then(function() {console.log('promise1')
  })
}, 0)
setTimeout(() => {console.log('timer2')
  Promise.resolve().then(function() {console.log('promise2')
  })
}, 0)
Promise.resolve().then(function() {console.log('promise3')
})
console.log('end')
//start=>end=>promise3=>timer1=>timer2=>promise1=>promise2 
  • 一开始执行栈的同步工作(这属于宏工作)执行结束后(顺次打印出 start end,并将 2 个 timer 顺次放入 timer 队列), 会先去执行微工作(这点跟浏览器端的一样),所以打印出 promise3
  • 而后进入 timers 阶段,执行 timer1 的回调函数,打印 timer1,并将 promise.then 回调放入 microtask 队列,同样的步骤执行 timer2,打印 timer2;这点跟浏览器端相差比拟大,timers 阶段有几个 setTimeout/setInterval 都会顺次执行,并不像浏览器端,每执行一个宏工作后就去执行一个微工作(对于 Node 与浏览器的 Event Loop 差别,下文还会具体介绍)。

3.Micro-TaskMacro-Task

Node 端事件循环中的异步队列也是这两种:macro(宏工作)队列和 micro(微工作)队列。

  • 常见的 macro-task 比方:setTimeoutsetIntervalsetImmediatescript(整体代码)I/O 操作等。
  • 常见的 micro-task 比方: process.nextTicknew Promise().then(回调)等。

4. 留神点

(1) setTimeoutsetImmediate

二者十分类似,区别次要在于调用机会不同。

  • setImmediate 设计在 poll 阶段实现时执行,即 check 阶段;
  • setTimeout 设计在 poll 阶段为闲暇时,且设定工夫达到后执行,但它在 timer 阶段执行
setTimeout(function timeout () {console.log('timeout');
},0);
setImmediate(function immediate () {console.log('immediate');
}); 
  • 对于以上代码来说,setTimeout 可能执行在前,也可能执行在后。
  • 首先 setTimeout(fn, 0) === setTimeout(fn, 1),这是由源码决定的
    进入事件循环也是须要老本的,如果在筹备时候破费了大于 1ms 的工夫,那么在 timer 阶段就会间接执行 setTimeout 回调
  • 如果筹备工夫破费小于 1ms,那么就是 setImmediate 回调先执行了

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

const fs = require('fs')
fs.readFile(__filename, () => {setTimeout(() => {console.log('timeout');
    }, 0)
    setImmediate(() => {console.log('immediate')
    })
})
// immediate
// timeout 

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

(2) process.nextTick

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

setTimeout(() => {console.log('timer1')
 Promise.resolve().then(function() {console.log('promise1')
 })
}, 0)
process.nextTick(() => {console.log('nextTick')
 process.nextTick(() => {console.log('nextTick')
   process.nextTick(() => {console.log('nextTick')
     process.nextTick(() => {console.log('nextTick')
     })
   })
 })
})
// nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1 

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

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

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

setTimeout(()=>{console.log('timer1')
    Promise.resolve().then(function() {console.log('promise1')
    })
}, 0)
setTimeout(()=>{console.log('timer2')
    Promise.resolve().then(function() {console.log('promise2')
    })
}, 0) 

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

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

Node 端运行后果分两种状况:

  • 如果是 node11 版本一旦执行一个阶段里的一个宏工作 (setTimeout,setInterval 和 setImmediate) 就立即执行微工作队列,这就跟浏览器端运行统一,最初的后果为timer1=>promise1=>timer2=>promise2
  • 如果是 node10 及其之前版本:要看第一个定时器执行完,第二个定时器是否在实现队列中。

    • 如果是第二个定时器还未在实现队列中,最初的后果为timer1=>promise1=>timer2=>promise2
    • 如果是第二个定时器曾经在实现队列中,则最初的后果为timer1=>timer2=>promise1=>promise2(下文过程解释基于这种状况下)

1. 全局脚本(main())执行,将 2 个 timer 顺次放入 timer 队列,main()执行结束,调用栈闲暇,工作队列开始执行;

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

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

Node 端的处理过程如下:

六、总结

浏览器和 Node 环境下,microtask 工作队列的执行机会不同

  • Node 端,microtask 在事件循环的各个阶段之间执行
  • 浏览器端,microtask 在事件循环的 macrotask 执行完之后执行
退出移动版