javascript技巧

关注公众号 jb51net

关闭
首页 > 网络编程 > JavaScript > javascript技巧 > 前端检查内存泄露

前端检查内存泄露完整示例

作者：遗憾随她而去.

内存泄漏是指应用程序中的内存被错误地分配和释放,导致无法再次使用的内存堆积,这通常是由于开发者忘记释放不再使用的对象或数据而引起的,这篇文章主要介绍了前端检查内存泄露的相关资料,需要的朋友可以参考下

前言

前端应用的内存泄露,指不再使用内存未被释放,导致页面占用内存持续增长,轻则引发页面卡顿,加载缓慢,重则导致浏览器崩溃, 尤其在单页应用SPA中,路由切换频繁但内存不回收,问题会被无限放大,比如用户长时间使用某后台管理系统,可能出现操作响应式延迟,甚至需要强制刷新才能恢复,这很可能是内存泄露在"作祟"

一. 前端常见的内存泄露场景

1. 意外的全局变量：未声明的变量（如a = 10而非let a = 10）会挂载到window上，页面不刷新就不会释放；

2. 闭包滥用：闭包会保留对外部作用域的引用，若长期持有 DOM 或大型对象，会导致内存无法回收（如未清理的事件监听回调) ;

3. 未清理的 DOM 引用：删除 DOM 节点后，仍保留其引用（如let el =       document.getElementById('test')，删除el对应的 DOM 后未置el = null）；

4. 定时器 / 事件监听未销毁：setInterval未用clearInterval清除、addEventListener未用removeEventListener解绑，尤其在组件挂载 / 卸载时容易遗漏；

5.第三方库 / 插件残留：部分第三方库（如图表库、播放器）使用后未调用销毁方法，导致内部资源无法释放；

6.数组 / 对象无限增长：全局缓存对象未设置过期机制，或数组持续 push 数据但未清理无效项。

二. 核心工具: 浏览器开发者工具(Chrome DevTools )

1.第一步: 复现内存泄露场景

首先需要稳定复现泄露行为,比如: 

路由切换（SPA 中反复切换 A→B→A→B）；

点击按钮触发某操作（如打开弹窗后关闭）；

长时间滚动或轮询请求数据。

2.第二步

1. 打开Chrome 开发者工具

2. 勾选面板顶部的「Memory」选项（同时可保留默认的「CPU」「Network」）；

3.点击左上角的「录制」按钮（圆形红点），然后执行复现步骤（如切换路由 5 次）；

4. 执行完成后点击「停止」，等待面板生成报告。

关键观察点: 

报告中[Memory]曲线若持续上升且不回落(即使操作停止后,内存仍未下降),则大概率存在泄露

若曲线在操作后能回落至初始水平,说明内存已正常回收,无泄露

3.第三步

用 Memory 面板定位泄露对象,主要是用于记录页面堆内存的具体情况以及js堆内存随加载时间线动态的分配情况

Performance 面板确认泄露后，用 Memory 面板进一步定位 “哪些对象未被回收”：

1. 常用快照类型

Memory面板支持3中快照类型,按需选择:

2. 堆快照对比操作

这时候就能看出变占用的内存大小,是那些操作造成了内存泄露

堆快照就像照相机一样,能记录你当前页面的堆内存情况,每快照一次就会产生一条快照记录

如上图所示，刚开始执行了一次快照，记录了当时堆内存空间占用为59.4MB，然后我们点击了页面中某些按钮，又执行一次快照，记录了当时堆内存空间占用为59.7MB。并且点击对应的快照记录，能看到当时所有内存中的变量情况（结构、占总占用内存的百分比...）

在开始记录后,我们可以看到图中右上角有起伏的蓝色与灰色的柱形图,其中蓝色表示当前时间线下占用着的内存; 灰色表示之前占用的内存空间已被清除释放

用Allocation on timeline 

三. 示例

1. 闭包使用不当引起内存泄漏

使用Performance和Memory来查看一下闭包导致的内存泄漏问题在退出fn1函数执行上下文后，该上下文中的变量a本应被当作垃圾数据给回收掉，但因fn1函数最终将变量a返回并赋值给全局变量res，其产生了对变量a的引用，所以变量a被标记为活动变量并一直占用着相应的内存，假设变量res后续用不到，这就算是一种闭包使用不当的例子

<button onclick="myClick()">执行fn1函数</button>
<script>
function fn1 () {
let a = new Array(10000) // 这里设置了一个很大的数组对象
let b = 3
function fn2() {
let c = [1, 2, 3]
}
fn2()
return a
}
let res = []
function myClick() {
res.push(fn1())
}
</script>

设置了一个按钮,每次执行就会将fn1函数的返回值添加到全局数组变量res中,是为了能在performacne的曲线图中看出效果 

使用Performance和Memory来查看一下闭包导致的内存泄漏问题

录制的时候去执行fn1 函数

先选择这个 

然后去录制 

在我们每次点击按钮后,动态内存分配情况图上都会出现一个蓝色的柱形,并且在我们触发垃圾回收后,蓝色柱形都没变成灰色柱形,即之前分配的内存并未被清除,即之前分配的内存并未被清除

所以此时我们就可以更明确得确认内存泄露的问题是存在的了,,接下来就精准定位问题,可以利用Heap snapshot来定位问题，如图所示：

以上就是一个判断闭包带来内存泄漏问题并简单定位的方法了

2.全局变量

全局的变量一般是不会被垃圾回收掉的当然这并不是说变量都不能存在全局，只是有时候会因为疏忽而导致某些变量流失到全局，例如未声明变量，却直接对某变量进行赋值，就会导致该变量在全局创建，如下所示：

function fn1() {
// 此处变量name未被声明
name = new Array(99999999)
}
fn1()

3.分离的DOM节点

假设你手动移除了某个dom节点，本应释放该dom节点所占用的内存，但却因为疏忽导致某处代码仍对该被移除节点有引用，最终导致该节点所占内存无法被释放，例如这种情况

<div id="root">
<div class="child">我是子元素</div>
<button>移除</button>
</div>
<script>
let btn = document.querySelector('button')
let child = document.querySelector('.child')
let root = document.querySelector('#root')
btn.addEventListener('click', function() {
root.removeChild(child)
})
</script>

该代码所做的操作就是点击按钮后移除.child的节点，虽然点击后，该节点确实从dom被移除了，但全局变量child仍对该节点有引用，所以导致该节点的内存一直无法被释放，可以尝试用Memory的快照功能来检测一下，如图所示

同样的先记录一下初始状态的快照，然后点击移除按钮后，再点击一次快照，此时内存大小我们看不出什么变化，因为移除的节点占用的内存实在太小了可以忽略不计，但我们可以点击第二条快照记录，在筛选框里输入detached，于是就会展示所有脱离了却又未被清除的节点对象

解决办法如下图所示：

<div id="root">
<div class="child">我是子元素</div>
<button>移除</button>
</div>
<script>
let btn = document.querySelector('button')

btn.addEventListener('click', function() {
let child = document.querySelector('.child')
let root = document.querySelector('#root')

root.removeChild(child)
})

</script>

改动很简单，就是将对.child节点的引用移动到了click事件的回调函数中，那么当移除节点并退出回调函数的执行上文后就会自动清除对该节点的引用，那么自然就不会存在内存泄漏的情况了，我们来验证一下，如下图所示：

结果很明显,这样处理过后就不存在内存泄露的情况了 

4. 控制台打印

<button>按钮</button>
<script>
document.querySelector('button').addEventListener('click', function() {
let obj = new Array(1000000)
console.log(obj);
})
</script>

我们在按钮的点击回调事件中创建了一个很大的数组对象并打印，用performance来验证一下

开始录制，先触发一次垃圾回收清除初始的内存，然后点击三次按钮，即执行了三次点击事件，最后再触发一次垃圾回收。查看录制结果发现JS Heap曲线成阶梯上升，并且最终保持的高度比初始基准线高很多，这说明每次执行点击事件创建的很大的数组对象obj都因为console.log被浏览器保存了下来并且无法被回收

接下来注释掉console.log，再来看一下结果

<button>按钮</button>
<script>
document.querySelector('button').addEventListener('click', function() {
let obj = new Array(1000000)
// console.log(obj);
})
</script>

可以看到没有打印以后，每次创建的obj都立马被销毁了，并且最终触发垃圾回收机制后跟初始的基准线同样高，说明已经不存在内存泄漏的现象了

5.遗忘的定时器

定时器也是平时很多人会忽略的一个问题，比如定义了定时器后就再也不去考虑清除定时器了，这样其实也会造成一定的内存泄漏。来看一个代码示例：

<button>开启定时器</button>
<script>
function fn1() {
let largeObj = new Array(100000)
setInterval(() => {
let myObj = largeObj
}, 1000)
}
document.querySelector('button').addEventListener('click', function() {
fn1()
})
</script>

这段代码是在点击按钮后执行fn1函数，fn1函数内创建了一个很大的数组对象largeObj，同时创建了一个setInterval定时器，定时器的回调函数只是简单的引用了一下变量largeObj，我们来看看其整体的内存分配情况吧：

按道理来说点击按钮执行fn1函数后会退出该函数的执行上下文，紧跟着函数体内的局部变量应该被清除，但图中performance的录制结果显示似乎是存在内存泄漏问题的，即最终曲线高度比基准线高度要高，那么再用Memory来确认一次：

<button>开启定时器</button>
<script>
function fn1() {
let largeObj = new Array(100000)
let index = 0

let timer = setInterval(() => {
if(index === 3) clearInterval(timer);
let myObj = largeObj
index ++
}, 1000)
}

document.querySelector('button').addEventListener('click', function() {
fn1()
})
</script>

现在我们再通过performance和memory来看看还不会存在内存泄漏的问题

总结 

到此这篇关于前端检查内存泄露的文章就介绍到这了,更多相关前端检查内存泄露内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

您可能感兴趣的文章:
阅读全文