浏览器进程与EventLoop

Fairy_妍
530 阅读8分钟

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第10天，点击查看活动详情。

javascript异步详解1:事件循环机制EventLoop种我们使用通过同步、异步。宏任务/微任务的循环执行详细讲解了浏览器中的EventLoop。

现在这篇文章换一个方向了解事件循环：JavaScript的进程线程、浏览器与Node中的事件循环。

浏览器进程与线程

浏览器中线程之间的关系

打开 1 个页面至少需要 1 个网络进程、1 个浏览器进程、1 个GPU 进程以及 1 个渲染进程，共 4 个；最新的 Chrome 浏览器包括：1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程。

  • 浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
  • 渲染进程：核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
  • GPU 进程：其实，Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
  • 网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
  • 插件进程：主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

线程之间的关系：

  • GUI渲染线程和JS引擎线程互斥：js是可以操作DOM的，如果在修改这些元素的同时渲染页面（js线程和ui线程同时运行），那么渲染线程前后获得的元素数据可能就不一致了。
  • JS阻塞页面加载：js如果执行时间过长就会阻塞页面

2007年之前，大多的浏览器都是单线程的，单线程浏览器的缺点：

  • 不稳定：一个插件的意外崩溃会引起整个浏览器的崩溃
  • 不流畅：所有页面的渲染模块、JavaScript执行环境以及插件都是运行在同一个线程中的，这就意味着同一时刻只能有一个模块可以执行
  • 不安全：可以通过浏览器的漏洞来获取系统权限，这些脚本获取系统权限之后也可以对你的电脑做一些恶意的事情，同样也会引发安全问题

多进程浏览器优点：

  • 默认新开 一个 tab 页面 新建 一个进程,所以单个 tab 页面崩溃不会影响到整个浏览器。
  • 第三方插件崩溃也不会影响到整个浏览器。
  • 多进程可以充分利用现代 CPU 多核的优势。
  • 方便使用沙盒模型隔离插件等进程,提高浏览器的稳定性。

进程与线程

进程（process）和线程（thread）是操作系统的基本概念。本质上来说，两个名词都是 CPU 工作时间片的一个描述。

  • 进程是 CPU 资源分配的最小单位（是能拥有资源和独立运行的最小单位）。
  • 线程是 CPU 调度的最小单位（是建立在进程基础上的一次程序运行单位）。

关系：

  1. 每个进程至少要做一件事,所以一个进程至少有一个线程。
  2. 系统会给每个进程分配独立的内存,因此进程有它独立的资源。
  3. 同一进程内的各个线程之间共享该进程的内存空间（包括代码段,数据集,堆等）。

进程可以理解为一个工厂不不同车间，相互独立。线程是车间里的工人，可以自己做自己的事情,也可以相互配合做同一件事情。

为什么JavaScript是单线程

  1. 因为JavaScript主要用途是与用户交互，操作DOM。如果JavaScript是多线程的，会带来很多复杂的问题。假如 JavaScript有A和B两个线程，A线程在DOM节点上添加了内容，B线程删除了这个节点，应该是哪个为准呢? 所以，为了避免复杂性，所以设计成了单线程。
  2. Web Worker为JavaScript 创造多线程环境，允许主线程创建 Worker 线程，将一些任务分配给后者运行。但是子线程完全受主线程控制，且不得操作DOM。所以这个并没有改变JavaScript单线程的本质。一般使用 Web Worker 的场景是代码中有很多计算密集型或高延迟的任务，可以考虑分配给 Worker 线程。
  3. worker 线程是为了让你的程序跑的更快，但是如果 worker 线程和主线程之间通信的时间大于了你不使用worker线程的时间，结果就得不偿失了。

任务队列

  • 单线程就意味着，所有任务都要排队执行，前一个任务结束，才会执行后一个任务。
  • 如果一个任务需要执行，但此时JavaScript引擎正在执行其他任务，那么这个任务就需要放到一个队列中进行等待。等到线程空闲时，就可以从这个队列中取出最早加入的任务进行执行（类似于我们去银行排队办理业务，单线程相当于说这家银行只有一个服务窗口，一次只能为一个人服务，后面到的就需要排队，而任务队列就是排队区，先到的就优先服务）

注意： 如果当前线程空闲，并且队列为空，那每次加入队列的函数将立即执行。

为什么会有任务队列？ 由于 JS 是单线程的，同步执行任务会造成浏览器的阻塞，所以我们将 JS 分成一个又一个的任务，通过不停的循环来执行事件队列中的任务。

执行栈

可以把执行栈认为是一个存储函数调用的栈结构，遵循先进后出的原则

function task1(){
 console.log('task1执⾏')
 task2()
 console.log('task2执⾏完毕')
}
function task2(){
 console.log('task2执⾏')
 task3()
 console.log('task3执⾏完毕')
}
function task3(){
 console.log('task3执⾏')
}
task1()
console.log('task1执⾏完毕')

/** 输出结果：
* task1执⾏
* task2执⾏
* task3执⾏
* task3执⾏完毕
* task2执⾏完毕
* task1执⾏完毕
*/

从这个执行结果可以看出，task1、task2、task3依次进栈，但是task3先出栈，然后是task2最后task1。就是一个先进后出的栈结构的特征。

递归函数就可以看成是在一个函数中嵌套n层执行，那么在执行过程中会触发大量的栈帧堆积，递归层数过多时，就可能导致执行栈的溢出。

浏览器的EventLoop

众所周知 JS 是门非阻塞单线程语言，因为在最初 JS 就是为了和浏览器交互而诞生的。

JS 在执行的过程中会产生执行环境，这些执行环境会被顺序的加入到执行栈中。如果遇到异步的代码，会被挂起并加入到 Task（有多种 task） 队列中。一旦执行栈为空，Event Loop 就会从 Task 队列中拿出需要执行的代码并放入执行栈中执行，所以本质上来说 JS 中的异步还是同步行为。

不同的任务源会被分配到不同的 Task 队列中，任务源可以分为 微任务（microtask） 和 宏任务（macrotask）。在 ES6 规范中，microtask 称为 jobs，macrotask 称为 task

image-20211229181842275.png

image-20220117210545751.png

微任务microtask

  • process.nextTick
  • promise
  • Object.observe
  • MutationObserver

宏任务macrotask

  • script
  • setTimeout
  • setInterval
  • setImmediate
  • I/O
  • UI rendering

宏任务中包括了 script ，浏览器会先执行一个宏任务，接下来有异步代码的话就先执行微任务

所以正确的一次 Event loop 顺序是这样的

  • 执行同步代码，这属于宏任务
  • 执行栈为空，查询是否有微任务需要执行
  • 执行所有微任务
  • 必要的话渲染 UI
  • 然后开始下一轮 Event loop，执行宏任务中的异步代码

通过上述的 Event loop 顺序可知，如果宏任务中的异步代码有大量的计算并且需要操作 DOM 的话，为了更快的响应界面响应，我们可以把操作 DOM 放入微任务中

Node中的Event loop

  • Node 中的 Event loop 和浏览器中的不相同。
  • Node 的 Event loop 分为6个阶段，它们会按照顺序反复运行
┌───────────────────────┐
┌─>│        timers         │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     I/O callbacks     │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     idle, prepare     │
│  └──────────┬────────────┘      ┌───────────────┐
│  ┌──────────┴────────────┐      │   incoming:   │
│  │         poll          │<──connections───     │
│  └──────────┬────────────┘      │   data, etc.  │
│  ┌──────────┴────────────┐      └───────────────┘
│  │        check          │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
└──┤    close callbacks    │
   └───────────────────────┘

2、timer

  • timers 阶段会执行 setTimeout 和 setInterval
  • 一个 timer 指定的时间并不是准确时间，而是在达到这个时间后尽快执行回调，可能会因为系统正在执行别的事务而延迟

2、I/O

  • I/O 阶段会执行除了 close 事件，定时器和 setImmediate 的回调

3、poll

  • poll 阶段很重要，这一阶段中，系统会做两件事情

    • 执行到点的定时器
    • 执行 poll 队列中的事件

  • 并且当 poll 中没有定时器的情况下，会发现以下两件事情

    • 如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者系统限制
    • 如果 poll 队列为空，会有两件事发生
    • 如果有 setImmediate 需要执行，poll 阶段会停止并且进入到 check 阶段执行 setImmediate
    • 如果没有 setImmediate 需要执行，会等待回调被加入到队列中并立即执行回调
    • 如果有别的定时器需要被执行，会回到 timer 阶段执行回调。

4、check

  • check 阶段执行 setImmediate

5、close callbacks

  • close callbacks 阶段执行 close 事件
  • 并且在 Node 中，有些情况下的定时器执行顺序是随机的

上面介绍的都是 宏任务 的执行情况，微任务 会在以上每个阶段完成后立即执行

示例1：

setTimeout(() => {
    console.log('setTimeout');
}, 0);
setImmediate(() => {
    console.log('setImmediate');
})
// 这里可能会输出 setTimeout，setImmediate
// 可能也会相反的输出: setImmediate, setTimeout，这取决于性能
// 因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate
// 否则会执行 setTimeout

上例setImmediate, setTimeout的先后顺序取决于性能

示例2：

setTimeout(() => {
  console.log('1')
  Promise.resolve().then(function () {
    console.log('2')
  })
}, 0)

setImmediate(() => {
  console.log('3')
  Promise.resolve().then(function () {
    console.log('4')
  })
})

以上代码在浏览器和 node 中打印情况是不同的

  1. 浏览器中一定打印 1，2，3，4
  2. node 中可能打印 1，2，3，4。也可能打印 3，4，1，2

Node 中的 process.nextTick 会先于其他 microtask 执行

setTimeout(() => {
 console.log("timer1");
 Promise.resolve().then(function() {
   console.log("promise1");
 });
}, 0);

process.nextTick(() => {
 console.log("nextTick");
});
// nextTick, timer1, promise1
avatar
文章
阅读
粉丝