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

5次阅读

共计 7363 个字符，预计需要花费 19 分钟才能阅读完成。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

浏览器端事件循环中的异步队列有两种：macro（宏工作）队列和 micro（微工作）队列。宏工作队列能够有多个，微工作队列只有一个。

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

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

Node.js 的运行机制如下:

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

其中 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 个阶段解决的。

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

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

1. 回到 timer 阶段执行回调

2. 执行 I/O 回调

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

如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者达到零碎限度
如果 poll 队列为空时，会有两件事产生
- 如果有 setImmediate 回调须要执行，poll 阶段会进行并且进入到 check 阶段执行回调
- 如果没有setImmediate 回调须要执行，会期待回调被退出到队列中并立刻执行回调，这里同样会有个超时工夫设置避免始终期待上来

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

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(回调)等。

(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 阶段去执行回调了。

这个函数其实是独立于 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

浏览器环境下，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 执行完之后执行

正文完

javascript

发表至： javascript

2021-03-11

0

JavaScript 是如何工作的：深入网络层 + 如何优化性能和安全

关于javascript:对容器镜像的思考和讨论

从 1 到完美，用 js 和 react-native 写一个 APP

蒲公英-JELLY技术周刊-Vol08-技术周刊-npm-install-g-typescript393

关于数据库:PostgreSQL高校数据库课程改革系列活动

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

前言

一、线程与过程

1. 概念

2. 多过程与多线程

二、浏览器内核

1.GUI 渲染线程

2.JS 引擎线程

3. 定时器触发线程

4. 事件触发线程

5. 异步 http 申请线程

三、浏览器中的 Event Loop

1.Micro-Task 与 Macro-Task

2.Event Loop 过程解析

四、Node 中的 Event Loop

1.Node 简介

2. 六个阶段

(1) timer

(2) poll

(3) check 阶段

3.`Micro-Task` 与 `Macro-Task`

4. 留神点

(1) `setTimeout` 和 `setImmediate`

(2) process.nextTick

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

六、总结

站内搜索

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

前言

一、线程与过程

1. 概念

2. 多过程与多线程

二、浏览器内核

1.GUI 渲染线程

2.JS 引擎线程

3. 定时器触发线程

4. 事件触发线程

5. 异步 http 申请线程

三、浏览器中的 Event Loop

1.Micro-Task 与 Macro-Task

2.Event Loop 过程解析

四、Node 中的 Event Loop

1.Node 简介

2. 六个阶段

(1) timer

(2) poll

(3) check 阶段

3.Micro-Task 与 Macro-Task

4. 留神点

(1) setTimeout 和 setImmediate

(2) process.nextTick

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

六、总结

站内搜索

3.`Micro-Task` 与 `Macro-Task`

(1) `setTimeout` 和 `setImmediate`