前言

这阵子接手的一个需求就是排查项目是否存在内存泄露问题，找到并解决它

目前是发现了四处问题，一处是 el-select 组件存在泄露问题，这个有做出挣扎解决，但是最终并没有彻底解决，无果；一初是项目封装的 v-delegate 指令存在闭包问题，这个最后是组长帮忙发现的，问题很隐蔽；另一个是有个 timer 没有 clear。最后一个还是闭包，这个就是本篇要讲的，排查过程比较煎熬

前端排查内存泄漏还是非常痛苦的，尤其是面对复杂项目

组里的项目是 黑盒语音 客户端，就是大家熟知的小黑盒旗下的一款语音产品，语音项目本身就对内存占用要求比较苛刻

其实排查内存泄漏，定位到是哪些交互其实还好，痛苦的是找到了交互过后，如何定位到具体代码，这次就是一个异步 + 闭包导致的内存泄露问题，开篇前先介绍下如何利用 performance 和 memory 选项卡定位可疑的交互

如何排查（先 performance 后 memory ）

该项目是 electron + vue2

比如这次碰到的问题是，语聊房的房间设置页面存在多个 tab，我针对所有 tab 依次往下点击然后回到最初的第一个 tab 看 performance 是否存在内存上涨

这里最好记得先把所有的 tab 点击加载一遍，防止有动态加载的组件存在，或者是缓存，异步函数等等。总之最好第一次先点击加载消除某些不可控的影响

这里提一嘴，排查内存泄漏最好是打包之后，或者保证自己的项目不存在 console.log（感觉手动剔除也不现实） ，因为你开启了 console 台后，log 会保存你的变量，这些变量会留在 windows 中导致内存泄露，打包之后一般 tree-shaking 会帮我们将项目的 log 给自动删除

好，现在我们来利用 performance 进行排查

从 第一个 tab 开始切换下面的所有 tab，然后回到第一个 tab

在录制之前保证点击了所有的 tab 后，开始录制时记得勾选 memory ，这个就是我们要看的 内存 信息，交互前先点击 🧹 图标，最后回到第一个 tab 后结束录制前也记得 点击 🧹 图标

最后我们来注意整个交互区间的 Nodes 上下浮动范围，从图中可以看出，节点从最初的 7000 个增长到了 8000 个左右，明显有内存泄露问题

这也就意味着这么多 tab ，存在一个或者多个导致了内存泄漏，正常来讲我回到页面最初起点，页面的 dom 数量也只会是最初的，增长了也就意味着 dom 可能被某些数据引用了，成了游离 dom，前端内存泄漏最大的问题其实就是游离 dom

接下来的分析方向就比较清晰了，我们需要排查究竟是哪个 tab 导致了内存泄露，后面的定位会比较繁琐，因为你要挨个排查，挨个排查你就得控制好变量，比如我怀疑第一个 tab，那么我就需要将其余 tab 的组件代码的 代码(template + script) 清空，然后针对第一个 tab 来回切换

中间的步骤这里不会展示，这里直接说结论了，就是第一个 tab 有问题，为了再次证明是这个 tab 的问题，我们接下来可以利用 memory 选项卡进行内存快照分析

为了有一个 tab 可以辅助切换，但是又不能有这个 tab 的影响，我就需要将其 template + Script 部分代码置空，比如这里我将 第二个 tab 代码置空

我们现在进行 memory 分析

可以看到第一个tab在与第二个空tab来回频繁切换 10 次后，js heap 上涨了将近 20M，这还是非常恐怖的数据

这个时候我们就可以去定位到是第一个 tab 这个组件的问题所在了，当然我们其实还是可以去继续留意 memory 的变化

我们会发现有两个 很奇怪的 constructor 增长了，一个 t 一个 a，我将这个项目放到 web 上去观察反而没有这两个变量，我们随机展开一个 t 看内部结构

会发现这应该是 vnode，这应该是因为 electron 跑的是代码压缩后的结果，还有个 a 应该是 VueComponent

其实内存快照的 comparison 这里也只有 t 好去分析，也就是 vnode，因为一个 vnode 会对应一个 dom 节点，我们可以看看究竟是哪里多出的 游离节点

其实当我们定位到某个组件的时候，我们还需要进一步分析，因为有些组件可能是由多个封装组件进一步封装的，或者会有多个同级 div，这个时候我们又需要去做一个控制变量分析，依次保留当前组件的某部分 template 然后去拍 内存快照，有时候可能是 js 问题，那又要控制 js 代码。

因为第一个 tab 组件比较复杂，所以这一步废了挺多时间去排查某个具体部分

其实定位到组件的时候，我们可以先目测观察下当前组件是否存在一些没有 off 掉的事件或者没有 clear 的定时器，然而事实却是 on 的事件都有对应的 off ，定时器也都有 clear，这就加大了排查难度

最后是定位到了一个 异步 methods，这个 methods 大致如下

其实这个 initData 中间还有很多逻辑，这里只展示了重点。乍这么一看好像也没啥问题，最后我定位的过程中，发现就是 judge 有问题，当我在 judge 中直接 return true 时没问题，只要一引用了 vuex 的值就会有泄露

这里的 channel_list 就是一个 vuex 的 store 值，我若是切换切得很快，这个 异步函数 在组件卸载时可能还没有执行完毕，后面的 initChannels 就会排队执行，这个 initChannels 里面的 judge 又是个 闭包函数，并且通过 vuex 引用了 this，vuex 本身就是全局唯一的状态管理库，这个值若牵扯到了 this，也就是 vue 实例，就会引起内存泄漏问题

所以怎么解决这个问题呢，我们可以在 await 后添加一个 逻辑，若组件卸载了就直接 return，不让继续执行后面的逻辑

这个泄露 bug 排查最后还是组长点醒我的

其实后面排查的过程中，因为用了组件库 element-ui，其中还有个 tab 用到了 el-select 组件，这个组件也存在内存泄露问题，好像 element-ui 但凡涉及到 popover 的组件都存在内存泄露问题，大家使用这个库的时候还是谨慎点

最后

当我们使用 performance 或者 memory 选项卡定位到了某个组件存在内存泄漏问题时，首先应该去判断组件是否存在某些事件没有清除，或者定时器没有 clear，这个是最重要的，若肉眼难以看出来，那就进一步去怀疑是否存在闭包导致的内存泄漏，然后去通过注释代码的方式去验证想法，过程还是非常麻烦的

现代浏览器的进程架构

进程之间是独立存在的，因此为了防止浏览器 tab 连续崩坏的情况，如今已经演变成了多进程架构，每个进程都会有个独立的内存空间

一般就是下面这六个进程：

1. 浏览器主进程（Browser Process）

• 负责管理浏览器的界面显示（比如导航栏）、用户交互、子进程管理
• 处理书签、历史记录、下载等功能
• 协调其他进程

2. 渲染进程（Renderer Process）

• 负责网页内容的渲染
• 每个标签页通常会有自己的渲染进程（沙箱隔离）
• 包含多个线程：
  • 主线程：处理JavaScript执行、DOM解析、CSS计算等
  • 合成线程：处理图层合成
  • 工作线程：处理Web Workers
  • 光栅化线程：将图形转换为位图

3. GPU进程（GPU Process）

• 处理GPU任务，加速图形渲染
• 负责将渲染进程的输出合成并显示到屏幕上

4. 网络进程（Network Process）

• 处理网络请求
• 实现HTTP/HTTPS协议
• 管理缓存

5. 插件进程（Plugin Process）

• 运行浏览器插件（如Flash）
• 每个插件通常有自己的进程

6. 实用程序进程（Utility Process）

• 处理一些辅助功能，如音频服务、打印等

在 windows 下，我们可以通过快捷键 Ctrl + Shift + Esc 来打开 windows 的实时进程，其实浏览器也有对应的界面，我们可以通过 Shift + Esc 来打开浏览器的实时进程

比如我这里开了两个 tab，首先每个 tab 都会存在一个独立的进程，这个进程就是我们说的渲染进程，图中可以看到 第一个 Chrome 图标的那个就是浏览器的主进程，第二个为 GPU 进程，第三个为 网络进程，第四个为 实用程序进程，然后后面几个 service worker 其实就是后台的特殊进程

其实早在 2018年，Chrome 就已经更新了一个名为 站点隔离（Site Isolation）的机制，这意味着不再是简单地一个标签页一个进程，而是按照网站的源（协议 + 域名 + 端口）来分配进程，这么做对于很多用户来讲应该可以很大程度减少 Chrome 内存占用，像是开发过程中你可能 csdn 会有很多 tab 同时存在，不过Chrome 会够根据用户的硬件设备调整不同的进程架构，像是站点隔离在内存受限的设备上就不会生效

实用程序进程这里可以看到是个 storage service ，这就是他处理存储的功能，当我们看 B站 视频时，就会存在一个 audio service，就说明在发挥它的 音频 功能

六个进程中我们了解大概就差不多了，但是渲染进程我们需要单独聊聊，这对前端仔来讲还是非常重要的

因为我们的前端代码均是在这个进程程执行的

渲染进程

渲染进程负责将 HTML，CSS 和 JS 转换为用户可以看到的网页内容和交互

渲染进程核心的职责就是我们熟知的下面五个步骤：

1. 解析HTML和CSS：将HTML转换为DOM树，将CSS转换为CSSOM树
2. 执行JavaScript：运行页面中的JavaScript代码
3. 布局计算：确定每个元素在屏幕上的确切位置和大小
4. 绘制：将元素绘制到内存中的位图
5. 合成：将不同的绘制层合成为最终显示的图像

若将渲染进程进行线程拆分，那么它主要是靠三个线程：主线程、合成线程和光栅线程

还有 工作线程（Web Workers），定时器线程，事件触发线程

我们的前端代码其实就是在 渲染进程中的 主线程 执行的，接下来我们引入事件循环来结合讲解

渲染主线程

渲染主线程负责渲染进程的大部分工作，所以它需要处理许多任务，执行 js 是它，绘制页面又是它，可能发生性能瓶颈，说 js 代码阻塞其实就是因为渲染主线程只有一个，无法同时处理两份属于自己的工作，渲染主线程的主要工作如下：

• 执行 JS 代码
• 处理 DOM 操作
• 处理用户事件（如 Click）
• 处理计时器回调
• 处理网络请求回调
• 执行微任务和宏任务

这个时候其实你可能会很好奇为何渲染主线程要做的东西这么多，也确实容易出现问题，那他为何不分配一些新的线程来做呢，比如专门给一个 js 线程来执行 js 代码，专门一个 dom 线程来处理 dom 操作

其实这个问题会有很多原因，其中我们最容易理解的就是因为 js 可以操作 dom，多个线程同时修改 dom 会导致难以预测的竞态条件；还有就是历史原因，js 最初就是个单线程语言，web 本身就非常向后兼容，改变这个线程模型就会破坏现有网站；再一个就是实际上浏览器已经采取了多线程优化方案，比如 WebWorker 新开了一个线程执行 js，但是这些 js 又不能直接访问 dom

事件循环（event-loop / message-loop）我们已经很熟悉了，但是想要真正理解透彻我们应该将 UI 渲染这一步骤结合进来

事件循环出来的目的也就是因为 js 执行变得复杂，此前单线程的原因并没有考虑这个问题，后来才逐步引入的机制，比如一个 for 循环很多次，执行的过程中某个定时器的回调也到了时间应该如何调度呢，如何调度其实就是事件循环，通俗理解这个东西就是让任务之间进行排队

事件循环在主线程上的工作流程如下：

1. 执行当前的 JS 调用栈中的所有同步代码
2. 检查微任务队列（microtask queue），执行所有微任务直到队列清空
3. 执行一个宏任务（macrotask）
4. 再次检查微任务队列，执行所有微任务
5. 如果需要，执行UI渲染
6. 返回步骤3，继续循环

我们再来复习下常见的宏微任务有哪些：

微任务

• Promise回调（.then/.catch/.finally）
• MutationObserver回调
• queueMicrotask() API
• 处理优先级较高，在每个宏任务之后立即执行

宏任务

• Script 标签
• setTimeout/setInterval回调
• 用户交互事件（点击、键盘输入等）
• 网络请求回调（XHR, fetch）
• MessageChannel
• requestAnimationFrame
• I/O操作

也许有人会争 宏任务比 同步先执行，这么说也是对的，因为本身 Script 就是个宏任务

执行 js 代码过程中，不一定会是当前执行代码所引入的 回调 进入消息队列，也有可能来自浏览器进程监听的用户交互，比如 click 事件，浏览器进程虽然不会执行 js 代码，js 执行是在渲染进程的渲染主线程中，浏览器进程可以监听事件然后放入消息队列，js 再从消息队列拿回调来执行

所以我们现在可以明白浏览器如何处理这些事件的，我们可以临时往消息队列中塞任务，但是执行就不一定是立即执行，因为他需要先等当前的调用栈执行完毕后，再依次检查消息队列中前面的事件是否执行完毕再去执行这个临时加的任务

event-loop 就是为了解决 js 单线程问题，异步的目的就是为了不让页面卡死，因为渲染这个关键步骤也是在 event-loop 之中或者说由渲染主线程负责

消息队列的优先级

消息队列可以理解为任务队列，我们在面试时常常会说宏任务队列，微任务队列，但是大家也清楚，其实宏任务这个概念官方已经抛弃了，此前宏任务就是 macrotask，现在官方换成了 task ，就是一个 任务，微任务依旧为 microtask

我也不清楚为何要换个名字，其实 task 和 macrotask 没有本质区别，因此我们完全可以沿用这个宏任务概念

对于 js 而言，任务是没有优先级的，它只管从 消息队列 依次去获取任务执行，这个任务就是回调，其实每个任务都会被浏览器包装成一个对象或者说是一个块

但是消息队列是具有优先级的，task queue 其实就是宏任务队列，因为浏览器的复杂程度越来越高，宏任务队列其实会被划分成不同的队列，有可能定时器会专门有一个定时器的队列，然后事件回调会有一个事件回调的队列，ui 渲染会专门有一个 渲染队列，这些队列具有优先级，另外，每种任务其实会专门放到对应的任务队列中，但是其实也可以放到其他不同的任务队列，比如监听事件的回调可以放到定时器队列，但是这样做后，它就不能放到其余的队列中了

这是 w3c 给出的规定，同一个类型必须在同一个队列，也可以分属不同的队列

宏任务细分下去的任务队列优先级其实不需要我们关注，我们只需要清楚微任务队列的优先级永远是最高的

不过对于宏任务队列而言，一般用户交互的事件队列是最高级的，比如点击，键盘，鼠标，其次再是 ui 渲染，这个也很好理解，为用户体验着想，总不可能用户点击后这个任务还有延迟执行吧，后面的优先级详细内容请看下面图示

有个地方需要特别留意，微任务优先级最高，这就意味着 高于 了 ui 渲染这个队列

另外，这里也可以看到定时器哪怕在宏任务队列中都是优先级较低的存在，就算不管微任务队列这个最高优先级，他的执行都是靠后的，因此他的计时肯定是不准的，因为他的回调需要等待前面的任务执行完毕才能继续执行，另外在 w3c 中有个 规定，定时器嵌套（nesting）层级超过了 5 层，后面的定时器就会增加 4 ms 的误差，其实浏览器的定时器实现本身就是调用的操作系统，操作系统本身的计时也是存在误差的，这点无法避免，真正准时的永远是原子钟

最后

总结下本文主要内容

浏览器有很多进程，但是对于前端仔来讲主要关注渲染进程，这个进程其实主要发挥作用的又是渲染主线程，由于前端代码都是在这个进程运行的，因此可以说 js 是个单线程语言，渲染其实也是个 task queue 类型，他的优先级还是比较高的，因此在一轮 event-loop 结束后，就是 ui 渲染线程开始执行