关于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 比方：setTimeout、setInterval、script（整体代码）、 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()(下文会介绍)

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

(1) timer

timers 阶段会执行 setTimeout 和 setInterval 回调，并且是由 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-Task` 与 `Macro-Task`

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

常见的 macro-task 比方：setTimeout、setInterval、 setImmediate、script（整体代码）、 I/O 操作等。
常见的 micro-task 比方: process.nextTick、new Promise().then(回调)等。

4.留神点

(1) `setTimeout` 和 `setImmediate`

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

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 执行完之后执行

前言