性能优化(二)：JS内存泄漏“探案”：从闭包到事件监听的隐形杀手
引子：那个越用越卡的网页
你一定有过这样的经历：刚打开一个网页时，它如丝般顺滑；但随着你不断地点击、浏览、交互，几个小时后，它变得越来越慢，越来越卡，甚至连打字都开始有延迟。最终，你忍无可忍，只能关闭标签页重开，世界才恢复清静。
这种现象，很多时候并非因为CPU计算量过大（上一章我们已经讨论了如何用时间分片来解决这个问题），而是另一个更隐蔽、更阴险的“性能杀手”在作祟——内存泄漏（Memory Leak）。
JavaScript是一门拥有自动垃圾回收（Garbage Collection, GC）机制的语言。理论上，当一个对象不再被任何其他活动对象所引用时，垃圾回收器就会认为它是“可回收的”，并在适当的时候释放它所占用的内存。
内存泄漏的本质是：程序中一些“不再需要”的对象，由于仍然被另一些“活动”的对象所引用，导致垃圾回收器无法将其回收，从而永久地滞留在内存中，积少成多，最终耗尽系统资源。
它就像一个房间里的垃圾桶，你以为你已经把垃圾扔了，但有一根看不见的细线，从垃圾桶连到了你口袋里的钥匙上。只要你还带着钥匙，清洁工（GC）就永远不会把这个垃圾桶收走。
内存泄漏的危害是巨大的：
- 性能下降：可用的内存越来越少，导致浏览器需要更频繁地触发垃圾回收，而GC本身是会阻塞主线程的，从而引发卡顿。
- 延迟增加：当内存紧张时，分配新内存的操作会变慢。
- 页面崩溃：当内存消耗超过了系统或浏览器设定的阈值，页面会直接崩溃。
今天，我们不写新功能。我们将化身“内存侦探”，通过几个经典的案例，学习如何发现、分析和修复那些最常见的JavaScript内存泄漏元凶。
案发现场一：被遗忘的定时器（The Forgotten Timer）
这是最常见，也最容易被忽视的内存泄漏场景。
罪案代码
想象我们有一个简单的组件，它每秒钟都需要更新一个计时器。当这个组件不再需要时，我们就从DOM中移除它。
// a-leaky-timer.js
// 一个模拟的“组件”
function createTimerComponent() {
const node = document.createElement('div');
node.id = 'timer-component';
const data = {
// 假设这是一个很大的数据对象，我们不希望它泄漏
bigData: new Array(10 * 1024 * 1024).fill('leak'),
message: 'Current time: '
};
// 启动一个定时器
const intervalId = setInterval(() => {
// 关键点：这个回调函数是一个闭包，它引用了外部的`node`和`data`变量
node.textContent = data.message + new Date().toLocaleTimeString();
}, 1000);
// 返回DOM节点和一个“销毁”函数
return {
node,
destroy: () => {
console.log('Timer component is being destroyed. Removing node from DOM.');
node.remove();
// 哦豁，我们忘了做什么？
}
};
}
// --- 模拟使用 ---
const timer = createTimerComponent();
document.body.appendChild(timer.node);
// 5秒后，我们“销毁”这个组件
setTimeout(() => {
timer.destroy();
}, 5000);
案情分析
我们调用了timer.destroy()，并且DOM节点也确实从页面上消失了。一切看起来都很好。但实际上，内存泄漏已经发生。
setInterval创建了一个持久的定时任务，它被注册在浏览器的事件调度器中。- 这个定时任务的回调函数是一个闭包。为了能访问
node和data来更新文本，这个闭包强引用了这两个变量。 - 只要这个定时器还在运行，闭包就存活着。
- 只要闭包存活着，它引用的
node和data（包括那个10MB的bigData数组！）就永远不会被垃圾回收。 - 我们虽然从DOM树上移除了
node，但它在内存中依然作为“游离的DOM节点”（Detached DOM node）存在。
结果：一个本应被销毁的组件，连同它持有的巨大数据对象和DOM节点，将永久地留在内存里。如果用户在我们的单页应用中反复创建和销-毁这样的组件，内存占用会线性增长，直到页面崩溃。
侦查手段：使用Chrome DevTools
-
Performance面板：
- 打开DevTools，进入Performance面板。
- 点击录制按钮（Record），刷新页面。
- 等待几秒钟（让组件销毁），然后停止录制。
- 在下方的详情区域，你会看到内存（Memory）图表。如果你勾选了它，你会看到内存占用在组件“销毁”后，并没有明显下降，甚至可能还在因为定时器回调的执行而有微小的波动。
-
Memory面板（Heap Snapshot）:
- 这是抓捕内存泄漏的王牌工具。
- 进入Memory面板，选择“Heap snapshot”。
- 步骤A: 页面加载完成后，点击“Take snapshot”按钮，拍下第一张快照。
- 步骤B: 等待组件“销毁”后（比如等5秒后），再次点击“Take snapshot”，拍下第二张快照。
- 在快照列表中，选择第二张快照，然后在下方的视图中，选择“Comparison”模式，并与第一张快照进行比较。
- 在“Class filter”中搜索
Detached，你很可能会找到被泄漏的“Detached HTMLDivElement”。点击它，在下方的“Retainers”视图中，你就能看到它的“引用链”，一层层追溯上去，最终你会发现罪魁祸首——那个setInterval的回调函数（system / Timeout）。
修复代码
修复方法非常简单：在组件销毁时，清除定时器。
// ...
return {
node,
destroy: () => {
console.log('Timer component is being destroyed. Clearing interval and removing node.');
// 唯一的修正：清除定时器
clearInterval(intervalId);
node.remove();
}
};
// ...
现在，当destroy被调用，clearInterval会取消定时任务。没有了定时任务，其回调闭包就会被回收。闭包被回收，它对node和data的引用就解除了。node和data不再被任何活动对象引用，GC就会在下一次运行时将它们彻底清理干净。
法则一：任何“订阅”式的行为（setInterval, setTimeout, addEventListener, ResizeObserver, IntersectionObserver等），都必须在不再需要时进行“退订”。
案发现场二：未解绑的事件监听器
这个案例与上一个非常相似，但更具欺骗性。
罪案代码
// a-leaky-listener.js
const bigDataObject = {
data: new Array(5 * 1024 * 1024).fill('other leak'),
id: 'big-data'
};
function setupLeakyComponent() {
const node = document.createElement('button');
node.textContent = 'Click me, I leak!';
document.body.appendChild(node);
const onClick = () => {
// 这个回调引用了外部的一个大对象
console.log('Button clicked!', bigDataObject.id);
};
node.addEventListener('click', onClick);
return {
destroy: () => {
console.log('Destroying leaky component...');
// 我们只移除了DOM节点，但监听器呢？
document.body.removeChild(node);
}
};
}
const leaky = setupLeakyComponent();
setTimeout(() => {
leaky.destroy();
}, 5000);
案情分析
- 我们创建了一个按钮
node，并给它添加了一个click事件的监听器onClick。 - 这个
onClick函数是一个闭包，它引用了外部的bigDataObject。 - 即使
node从DOM树中被移除了，但它本身并没有被销毁。JavaScript引擎中，这个node对象依然存在，并且它的事件监听器列表中，依然保有对onClick函数的引用。 - 只要
node对象还持有对onClick的引用，onClick闭包就无法被回收。 - 只要
onClick闭包无法被回收，它引用的bigDataObject就也无法被回收。
这是一个更隐蔽的“游离DOM节点”泄漏。
修复代码
同样，修复方案是在销毁时，明确地解绑事件监听器。
// ...
return {
destroy: () => {
console.log('Destroying leaky component correctly...');
// 必须手动解绑
node.removeEventListener('click', onClick);
document.body.removeChild(node);
}
};
// ...
法则二：谁add，谁remove。 在哪个作用域添加的事件监听，就应该在哪个作用域负责清理。在现代框架中，框架的生命周期方法或useEffect的清理函数，就是执行这个清理操作的最佳场所。
案发现场三：致命的循环引用
这是最经典的内存泄漏场景，尤其是在旧版本的IE浏览器中，因为其GC算法的缺陷（基于引用计数），循环引用是致命的。在现代浏览器中，虽然GC使用了更先进的“标记-清除”（Mark-and-Sweep）算法，可以处理大多数JS对象间的循环引用，但当循环引用涉及到DOM节点和JavaScript对象时，问题就变得复杂起来。
罪案代码
// a-circular-reference.js
function createCircularReference() {
const node = document.createElement('div');
document.body.appendChild(node);
const customData = {
// JS对象持有一个对DOM节点的引用
domElement: node,
// 一些其他数据
payload: new Array(2 * 1024 * 1024).fill('circular')
};
// DOM节点通过一个自定义属性，反向持有一个对JS对象的引用
node.myCustomData = customData;
// 销毁函数
return {
destroy: () => {
console.log('Attempting to destroy circular reference...');
document.body.removeChild(node);
}
};
}
const circular = createCircularReference();
setTimeout(() => {
circular.destroy();
// 在这里，我们期望node和customData都被回收
// 但它们会泄漏吗？
}, 5000);
案情分析
- 我们创建了一个
node（DOM对象）和一个customData（JS对象）。 customData.domElement引用了node。 (JS -> DOM)node.myCustomData引用了customData。 (DOM -> JS)- 一个完美的循环引用形成了。
- 当我们调用
destroy时，我们只是切断了document.body对node的引用。但是，node和customData之间的小圈子依然存在。
在现代浏览器中，这种特定情况通常能被GC正确处理。标记-清除算法会从根对象（如window）开始遍历，找不到任何路径可以到达这个由node和customData组成的小岛，于是会将整个小岛判定为“可回收”。
但是，依赖GC的“聪明才智”是危险的编程实践。 在某些复杂的场景、特定的浏览器版本或涉及原生模块（如WebAssembly）的交互中，这种循环引用依然是导致内存泄漏的常见原因。
修复代码：打破循环
最健壮的做法，是在销毁时，明确地打破这个循环。
// ...
return {
destroy: () => {
console.log('Destroying circular reference correctly...');
// 在移除DOM前，先打破循环
if (node.myCustomData) {
node.myCustomData.domElement = null; // JS -> DOM 的引用断开
}
node.myCustomData = null; // DOM -> JS 的引用断开
document.body.removeChild(node);
}
};
// ...
通过在销毁前手动将其中一条引用设置为null，我们主动打破了这个环，让GC可以毫无疑问地、轻松地回收这两个对象。
法则三：在组件或对象的生命周期结束时，有意识地解除可能存在的循环引用，特别是在JS对象和DOM/BOM对象之间。
结论：成为一名有“内存洁癖”的开发者
内存泄漏不像功能性Bug那样显眼，它像温水煮青蛙，悄无声息地侵蚀着你的应用性能和稳定性。成为一名优秀的工程师，不仅要会“创造”功能，更要会“管理”资源。
通过今天的“探案”，我们掌握了识别和修复几种最常见内存泄漏的方法。
核心要点回顾：
- 内存泄漏的本质：不再需要的对象，因为仍然被活动对象引用，而无法被GC回收。
- 被遗忘的定时器：
setInterval和setTimeout的回调闭包会引用外部变量，必须在销毁时用clearInterval/clearTimeout来清除。 - 未解绑的事件监听：DOM节点即使从文档树移除，其绑定的事件监听器依然存活，必须用
removeEventListener手动解绑。 - 循环引用：尤其需要警惕JS对象和DOM对象之间的循环引用，在销毁时应主动打破环。
- 养成良好习惯：“谁创建，谁销毁；谁订阅，谁退订；谁引用，谁释放”。将资源的清理工作，与对象的生命周期紧密绑定，是避免内存泄漏的根本之道。
在下一章 《性能优化(三)：Tree Shaking的艺术：不是“摇掉”代码，而是“构建”最小依赖图》 中，我们将把视线从运行时的内存性能，转向构建时的体积性能。我们将深入探讨现代打包工具（Webpack/Vite）的核心优化功能——Tree Shaking，看看它是如何通过分析ESM的静态结构，为我们移除“死代码”，打造出极致精简的最终产物的。敬请期待！
扫一扫
27
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
