利用 Chrome Memory Profile 追踪内存泄漏：寻找 Retained Size 的源头 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位开发者，下午好！

今天，我们将深入探讨一个在前端开发中常常被忽视，却又至关重要的话题：内存泄漏。尤其是在大型、复杂的单页应用（SPA）中，内存泄漏不仅会导致应用程序性能下降，还会带来卡顿、崩溃乃至用户流失等一系列严重问题。而 Chrome 开发者工具中的 Memory Profile，正是我们手中的一把利剑，尤其当我们学会如何利用它来追踪“Retained Size”的源头时，内存泄漏将无处遁形。

我将以一次技术讲座的形式，带领大家系统地学习如何利用 Chrome Memory Profile 追踪内存泄漏，特别是关注那些被不当保留的内存，即“Retained Size”。

内存泄漏的本质：垃圾回收机制的盲点

在 JavaScript 这样的高级语言中，我们通常不需要手动管理内存。垃圾回收器（Garbage Collector, GC）会自动识别并回收不再被引用的对象所占用的内存。然而，这并非万无一失。当一个对象尽管在逻辑上已经不再需要，但仍然存在可达的引用链，导致垃圾回收器无法将其回收时，内存泄漏就发生了。

想象一下，你的应用在执行某个操作时创建了大量的对象。如果这些对象在操作结束后仍然被某个地方引用着，即使它们的功能已经完成，它们所占据的内存也无法被释放。随着时间的推移，这样的对象越来越多，内存占用持续增长，最终拖垮整个应用。

常见的内存泄漏场景

在前端应用中，内存泄漏的原因多种多样，但通常可以归结为以下几类：

全局变量或意外的全局引用： 不小心创建了全局变量，或者在模块化环境中将对象挂载到 window 或其他全局对象上，而没有及时清理。
闭包： 闭包是 JavaScript 的强大特性，但也容易导致内存泄漏。如果一个内部函数引用了外部函数作用域中的变量，并且这个内部函数被长期持有（例如作为事件处理器或定时器回调），那么外部函数作用域中的变量即使不再需要，也无法被回收。
定时器（setInterval, setTimeout）： 定时器在创建后会一直运行，直到被手动清除。如果定时器回调函数引用了外部变量，并且定时器本身没有被清除，那么这些变量也会被保留。
事件监听器： 如果在一个 DOM 元素上注册了事件监听器，但在该 DOM 元素被移除时，没有移除对应的监听器，那么即使 DOM 元素从文档中被移除，它的引用仍然可能存在于事件系统中，导致 DOM 元素及其关联数据无法被回收。
脱离 DOM 树的 DOM 元素（Detached DOM Tree）： 当一个 DOM 元素从文档中被移除，但 JavaScript 代码仍然保留着对它的引用时，这个元素及其子树就会形成一个“脱离 DOM 树”，无法被垃圾回收。
缓存： 有时为了性能优化，我们会实现一些缓存机制。如果缓存没有适当的失效策略，或者缓存的对象没有被正确清理，就会导致内存持续增长。
WeakMap 和 WeakSet 的误用或未使用： 对于一些需要弱引用的场景（例如缓存 DOM 元素或对象），如果使用了 Map 或 Set 而不是 WeakMap 或 WeakSet，就可能导致内存泄漏。

理解这些常见场景是第一步，接下来，我们将学习如何用工具去识别它们。

Chrome Memory Profile：内存泄漏的侦查工具

Chrome 开发者工具中的 Memory 面板提供了强大的内存分析能力。它主要有三种类型的记录方式：

Heap snapshot (堆快照)： 记录当前时刻 JavaScript 堆中所有对象的快照。这是我们今天追踪内存泄漏的主要工具。
Allocation instrumentation on timeline (时间线上的分配检测)： 记录一段时间内内存分配的变化。可以帮助我们观察内存分配的模式和峰值。
Allocation sampling (分配采样)： 以采样的方式记录内存分配，开销较小，适合长时间运行的测试。

我们将主要聚焦于“Heap snapshot”，因为它能提供最详细的对象信息，包括它们的大小、引用关系以及最重要的——Retained Size。

启动 Memory Profile

打开 Chrome 浏览器。
打开开发者工具（通常是 F12 或 Ctrl+Shift+I / Cmd+Option+I）。
切换到 Memory 面板。

深入理解堆快照（Heap Snapshot）

堆快照是内存分析的核心。点击 Take snapshot 按钮，Chrome 会捕获当前 JavaScript 堆的完整视图。

堆快照视图解读

一个典型的堆快照视图包含以下几个关键区域：

构造函数（Constructor）： 列出所有 JavaScript 对象的构造函数名称。你可以看到 Array、Object、String、HTMLDivElement 等等。
对象列表（Objects List）： 展开一个构造函数，可以看到该类型的所有实例对象。
引用路径（Retainers）： 当你选中一个对象时，下方会显示它的引用路径，即哪些对象正在引用它，导致它无法被垃圾回收。这条路径通常被称为“GC Root Path”。
统计信息：
- Distance (距离)： 从 GC 根（通常是 window 或全局对象）到该对象的“最短路径”的长度。距离越近，说明它越接近全局可访问的根对象，被保留的可能性越大。
- Shallow Size (浅层大小)： 对象本身直接占用的内存大小，不包括它引用的其他对象。例如，一个数组的浅层大小是它自身结构所需的内存，而不是它存储的元素所占的内存。
- Retained Size (保留大小)： 这是我们今天的主角！它表示当这个对象及其所有依赖它的对象（如果它们不再被其他任何对象引用的话）都被垃圾回收时，总共可以释放的内存大小。简单来说，Retained Size 就是这个对象“阻止”垃圾回收器回收的总内存量。

Retained Size 的重要性

Shallow Size 只能告诉你一个对象自身的大小，而 Retained Size 才能真正揭示一个对象对整体内存占用的影响。一个对象可能 Shallow Size 很小，但如果它间接引用了一个庞大的对象图，那么它的 Retained Size 就会非常大。这意味着，只要这个“小”对象不被回收，那么它所间接引用的所有“大”对象也无法被回收。

我们的目标就是找到那些 Retained Size 异常大，但逻辑上应该已经被回收的对象。

内存泄漏追踪实战：利用堆快照比较功能

最强大的内存泄漏追踪技术是使用堆快照的比较功能。其核心思想是：在执行可能导致泄漏的操作前后，分别拍摄堆快照，然后比较两次快照之间的差异。

追踪内存泄漏的通用步骤

建立基线： 确保应用处于一个“干净”的状态，例如刚加载完页面，或者所有初始化操作都已完成。在 Memory 面板中，选择 Heap snapshot，然后点击 Take snapshot 按钮。这将是你的“快照 1”。
执行可疑操作： 在应用程序中执行你怀疑可能导致内存泄漏的操作。例如，打开一个弹窗、导航到一个页面、进行数据加载、反复点击某个按钮等。
清理操作（如果可能）： 如果你的操作是临时的（例如关闭弹窗、返回上一页），请执行相应的清理操作。
强制垃圾回收： 在某些情况下，为了确保所有不再引用的对象都被回收，我们可以手动触发垃圾回收。在 Chrome 开发者工具中，点击 Memory 面板上的垃圾桶图标（Collect garbage）或者在 Console 中输入 window.gc()（注意：window.gc() 默认不可用，需要启动 Chrome 时带上 --expose-gc 命令行参数。对于生产环境排查，通常不需要强制，因为 GC 会自动运行，而我们关注的是“无法被回收”的对象）。
再次拍摄快照： 再次点击 Take snapshot 按钮，拍摄“快照 2”。
比较快照： 在快照列表中，选择“快照 2”，然后在顶部的下拉菜单中选择“Comparison”模式，并选择与“快照 1”进行比较。

比较视图解读

在比较视图中，最重要的列是：

#New： 在快照 2 中新增的该类型对象数量。
#Deleted： 在快照 2 中被删除的该类型对象数量。
#Delta： 新增数量减去删除数量。正值表示增加了，负值表示减少了。
Added Size： 新增对象的 Shallow Size 总和。
Deleted Size： 删除对象的 Shallow Size 总和。
Delta Size： Added Size 减去 Deleted Size。
Added Retained Size： 新增对象的 Retained Size 总和。
Deleted Retained Size： 删除对象的 Retained Size 总和。
Delta Retained Size： 新增 Retained Size 减去 Deleted Retained Size。这是我们重点关注的指标！

寻找泄漏的关键：

在比较视图中，我们通常会按 Delta Retained Size 降序排列。如果某个对象类型在执行操作后，其 Delta Retained Size 显著增加，并且 Delta（对象数量变化）也为正值，那么它极有可能就是内存泄漏的源头。

例如，如果你执行了一个操作，然后关闭了弹窗，期望所有与弹窗相关的对象都被回收。但在比较快照后，你发现 HTMLDivElement、Closure 或某个自定义类的对象数量和 Delta Retained Size 仍然很高，这就说明这些对象被不当地保留了。

接下来，我们将通过几个具体的代码示例，演示如何运用上述步骤来发现并解决内存泄漏。

案例分析：寻找 Retained Size 的源头

案例一：脱离 DOM 树的 DOM 元素泄漏

场景： 我们有一个列表，点击按钮会加载新的列表项，并替换旧的列表。但由于不当的代码，旧的列表元素并没有被完全释放。

泄漏代码示例：

// index.html
<body>
    <div id="app">
        <button id="loadMore">加载更多数据 (可能导致泄漏)</button>
        <div id="container">
            <!-- 初始或加载后的列表会在这里 -->
        </div>
    </div>
    <script src="leak-dom.js"></script>
</body>

// leak-dom.js
let detachedElementsCache = []; // 模拟一个不当的缓存，保留了旧的DOM引用

function createListItems(count) {
    const ul = document.createElement('ul');
    for (let i = 0; i < count; i++) {
        const li = document.createElement('li');
        li.textContent = `Item ${Date.now()}-${i}`;
        ul.appendChild(li);
    }
    return ul;
}

document.getElementById('loadMore').addEventListener('click', () => {
    const container = document.getElementById('container');

    // 模拟一个不当的逻辑：旧的元素虽然从DOM中移除了，但被我们不小心缓存了
    if (container.firstChild) {
        detachedElementsCache.push(container.firstChild); // BUG: 强引用了旧的DOM元素
        console.log(`Cached ${detachedElementsCache.length} detached elements.`);
    }

    // 清空容器并添加新的列表
    container.innerHTML = ''; // 移除旧的DOM元素
    container.appendChild(createListItems(100));
});

// 为了演示，我们故意不清理 detachedElementsCache
// 在实际应用中，这可能是因为某个组件内部的引用没有被及时清除

追踪步骤：

基线快照： 加载 index.html 页面，点击 Take snapshot。
执行可疑操作： 反复点击 加载更多数据 (可能导致泄漏) 按钮 3-5 次。观察页面内容变化。
强制垃圾回收： （可选，但有助于验证）点击垃圾桶图标。
再次快照： 再次点击 Take snapshot。
比较快照： 选择第二个快照，在下拉菜单中选择与第一个快照比较。

分析结果：

在比较视图中，你会发现 Detached DOM tree 或者 HTMLUListElement (或其他具体的 DOM 元素类型) 的 Delta 值和 Delta Retained Size 显著增加。

Constructor	#New	#Delta	Delta Retained Size
(array)	1	1	88 B
HTMLUListElement	4	4	15.6 KB
HTMLLIElement	400	400	240 KB
(string)	400	400	40 KB
Detached DOM tree	–	–	~280 KB
…	…	…	…

（注意：Detached DOM tree 本身不是一个构造函数，而是 Chrome DevTools 对被保留的脱离 DOM 元素的聚合显示，你可能在具体的元素类型如 HTMLUListElement 或 HTMLLIElement 下看到其增加的 Retained Size。）

展开 HTMLUListElement 或 HTMLLIElement，找到那些 Delta 为正且 Retained Size 较大的对象。选中其中一个，在下方的 Retainers 面板中，你会看到它的引用路径。很可能你会看到 (array) 引用了它，进一步追踪，会发现是 detachedElementsCache 这个全局数组强引用了这些本该被回收的 DOM 元素。

解决方案：

确保不再需要的 DOM 元素不再被 JavaScript 代码引用。在本例中，我们应该避免将旧的 DOM 元素缓存起来，或者在不再需要时清理缓存。

// leak-dom-fixed.js
// let detachedElementsCache = []; // 移除不当的缓存

function createListItems(count) {
    const ul = document.createElement('ul');
    for (let i = 0; i < count; i++) {
        const li = document.createElement('li');
        li.textContent = `Item ${Date.now()}-${i}`;
        ul.appendChild(li);
    }
    return ul;
}

document.getElementById('loadMore').addEventListener('click', () => {
    const container = document.getElementById('container');

    // 正确的做法：直接清空并替换。旧的DOM元素如果没有其他引用，会被GC回收。
    container.innerHTML = '';
    container.appendChild(createListItems(100));

    // 如果有其他复杂的DOM操作，需要确保旧的DOM元素及其子元素上的所有事件监听器和数据引用都被清除
    // 例如：如果旧的container.firstChild上有复杂的组件实例，需要调用其destroy方法
});

验证： 替换代码后，重复上述追踪步骤。这次你会发现 Detached DOM tree 相关的 Delta Retained Size 应该接近于零，或者仅有少量波动，表明泄漏已修复。

案例二：闭包导致的大对象泄漏

场景： 一个函数创建了一个大对象，并返回了一个内部函数。如果这个内部函数被长期持有，并且它捕获了外部函数作用域中的大对象，那么大对象就无法被回收。

泄漏代码示例：

// index.html
<body>
    <button id="createLeak">创建泄漏闭包</button>
    <button id="clearLeak">尝试清理泄漏</button>
    <script src="leak-closure.js"></script>
</body>

// leak-closure.js
let leakyClosures = []; // 用于存储泄漏的闭包

function createLeakyClosure() {
    const bigData = new Array(1000000).fill('some big data string'); // 1MB 左右

    // 这个内部函数捕获了 bigData
    const innerFunction = function() {
        console.log('Accessing bigData length:', bigData.length);
    };

    leakyClosures.push(innerFunction); // BUG: 内部函数被长期持有，导致 bigData 无法释放
    console.log(`Created leaky closure. Total: ${leakyClosures.length}`);
    return innerFunction;
}

document.getElementById('createLeak').addEventListener('click', createLeakyClosure);

document.getElementById('clearLeak').addEventListener('click', () => {
    leakyClosures = []; // 尝试清空数组
    console.log('Cleared leakyClosures array. Waiting for GC...');
});

追踪步骤：

基线快照： 加载 index.html 页面，点击 Take snapshot。
执行可疑操作： 反复点击 创建泄漏闭包 按钮 3-5 次。
尝试清理： 点击 尝试清理泄漏 按钮。
强制垃圾回收： （可选）点击垃圾桶图标。
再次快照： 再次点击 Take snapshot。
比较快照： 选择第二个快照，与第一个快照比较。

分析结果：

在比较视图中，你会发现 (closure) 类型的对象数量和 Delta Retained Size 显著增加。

Constructor	#New	#Delta	Delta Retained Size
(array)	1	1	88 B
(string)	5	5	1.1 MB
(closure)	5	5	~5 MB
Array	5	5	~5 MB
…	…	…	…

你会看到 Array 对象的 Delta 和 Delta Retained Size 也在增加，这正是 bigData 数组。
展开 (closure)，找到那些 Retained Size 较大的闭包。选中其中一个，在 Retainers 面板中，你会看到它的引用路径。它会被 leakyClosures 数组引用，并且它的 [[Scopes]] 属性会显示它捕获了 createLeakyClosure 作用域中的 bigData 变量。

解决方案：

避免闭包不必要地捕获大对象。如果内部函数确实需要访问外部变量，确保这些变量是轻量级的，或者在不再需要时显式地将它们置为 null。在本例中，leakyClosures 数组本身就是问题所在，它不应该长期持有这些闭包。

// leak-closure-fixed.js
let activeClosures = []; // 修改命名，强调仅保留活跃的闭包

function createClosureEfficiently() {
    const smallData = "small string"; // 确保捕获的数据是轻量级的

    // 如果必须捕获大对象，考虑使用工厂模式或传递参数
    // 或者确保闭包的生命周期与大对象一致，并在大对象不再需要时，解除闭包的引用
    const innerFunction = function() {
        console.log('Accessing smallData:', smallData);
        // 如果需要大对象，可以考虑在需要时才创建或通过参数传递
        // const bigData = new Array(1000000).fill('some big data string'); 
        // console.log(bigData.length);
    };

    // 假设我们只保留一个最新的闭包，或者有明确的清理策略
    if (activeClosures.length >= 1) {
        // 显式解除对旧闭包的引用，让GC回收
        activeClosures[0] = null; 
        activeClosures.pop();
    }
    activeClosures.push(innerFunction); 
    console.log(`Created efficient closure. Total: ${activeClosures.length}`);
    return innerFunction;
}

document.getElementById('createLeak').addEventListener('click', createClosureEfficiently);

document.getElementById('clearLeak').addEventListener('click', () => {
    activeClosures = []; // 清空数组，解除所有闭包引用
    console.log('Cleared activeClosures array. Waiting for GC...');
});

验证： 替换代码后，重复上述追踪步骤。这次你会发现 (closure) 和 Array 相关的 Delta Retained Size 应该不再持续增长，或者增长后能被及时清理。

案例三：未移除的事件监听器泄漏

场景： 在一个组件被销毁后，它仍然在全局对象（如 window 或 document）上保留了事件监听器。

泄漏代码示例：

// index.html
<body>
    <button id="createComponent">创建组件</button>
    <button id="destroyComponent">销毁组件</button>
    <script src="leak-event.js"></script>
</body>

// leak-event.js
let componentInstance = null;

class LeakyComponent {
    constructor(name) {
        this.name = name;
        this.bigInternalData = new Array(500000).fill('component data'); // 模拟大对象
        this.handleClick = this.handleClick.bind(this); // 绑定this

        // BUG: 在全局对象上添加监听器，但没有在销毁时移除
        window.addEventListener('resize', this.handleClick); 
        console.log(`${this.name} created.`);
    }

    handleClick(event) {
        console.log(`${this.name} received resize event. Data size: ${this.bigInternalData.length}`);
    }

    destroy() {
        // BUG: 缺少移除事件监听器的代码
        // window.removeEventListener('resize', this.handleClick); 
        console.log(`${this.name} destroyed (but event listener might leak).`);
        this.bigInternalData = null; // 尝试清理内部数据，但如果事件监听器不移除，它仍然会保留this
    }
}

document.getElementById('createComponent').addEventListener('click', () => {
    if (componentInstance) {
        componentInstance.destroy();
    }
    componentInstance = new LeakyComponent('MyLeakyComponent');
});

document.getElementById('destroyComponent').addEventListener('click', () => {
    if (componentInstance) {
        componentInstance.destroy();
        componentInstance = null; // 解除对组件实例的引用
        console.log('Component instance cleared. Waiting for GC...');
    }
});

追踪步骤：

基线快照： 加载 index.html 页面，点击 Take snapshot。
执行可疑操作： 点击 创建组件 按钮。
销毁组件： 点击 销毁组件 按钮。
强制垃圾回收： （可选）点击垃圾桶图标。
再次快照： 再次点击 Take snapshot。
比较快照： 选择第二个快照，与第一个快照比较。

分析结果：

在比较视图中，你会发现 LeakyComponent 实例的 Delta 应该为 0（因为我们尝试清除了 componentInstance），但其 Delta Retained Size 可能依然很高。

Constructor	#New	#Delta	Delta Retained Size
(closure)	1	1	500 KB
LeakyComponent	1	1	500 KB
Array	1	1	500 KB
EventListener	1	1	88 B
…	…	…	…

你会看到 LeakyComponent 和 Array ( bigInternalData ) 的 Delta 可能是 0，但 Delta Retained Size 却有明显增加。更重要的是，你可能会发现 EventListener 类型的对象数量在增加。

展开 EventListener，找到新增的对象。选中它，在 Retainers 面板中，你会看到它被 window 对象引用，并且它的 handler 属性指向了 LeakyComponent 实例的 handleClick 方法。这意味着，尽管 componentInstance = null 尝试清除了对组件的引用，但 window 仍然通过事件监听器间接引用了 LeakyComponent 实例，导致 LeakyComponent 及其内部的 bigInternalData 无法被回收。

解决方案：

始终在组件销毁时，移除所有在全局对象或其他长生命周期对象上注册的事件监听器。

// leak-event-fixed.js
let componentInstance = null;

class FixedComponent {
    constructor(name) {
        this.name = name;
        this.bigInternalData = new Array(500000).fill('component data');
        this.handleClick = this.handleClick.bind(this);

        window.addEventListener('resize', this.handleClick); 
        console.log(`${this.name} created.`);
    }

    handleClick(event) {
        console.log(`${this.name} received resize event. Data size: ${this.bigInternalData.length}`);
    }

    destroy() {
        // 关键修复：移除事件监听器
        window.removeEventListener('resize', this.handleClick); 
        console.log(`${this.name} destroyed. Event listener removed.`);
        this.bigInternalData = null; // 清理内部数据
    }
}

document.getElementById('createComponent').addEventListener('click', () => {
    if (componentInstance) {
        componentInstance.destroy();
    }
    componentInstance = new FixedComponent('MyFixedComponent');
});

document.getElementById('destroyComponent').addEventListener('click', () => {
    if (componentInstance) {
        componentInstance.destroy();
        componentInstance = null; 
        console.log('Component instance cleared. Waiting for GC...');
    }
});

验证： 替换代码后，重复上述追踪步骤。这次你会发现 LeakyComponent、Array 和 EventListener 相关的 Delta Retained Size 应该在组件销毁后被正确回收，接近于零。

案例四：全局变量或不当缓存导致泄漏

场景： 应用程序维护一个全局的缓存对象，但没有清理机制，导致缓存持续增长。

泄漏代码示例：

// index.html
<body>
    <button id="addData">添加数据到缓存</button>
    <button id="clearCache">清理缓存</button>
    <script src="leak-cache.js"></script>
</body>

// leak-cache.js
const globalCache = {}; // 模拟一个全局缓存

function generateLargeObject(id) {
    return {
        id: id,
        timestamp: Date.now(),
        data: new Array(200000).fill(`data for ${id}`) // 200KB 左右
    };
}

let counter = 0;
document.getElementById('addData').addEventListener('click', () => {
    const key = `item_${counter++}`;
    globalCache[key] = generateLargeObject(key); // BUG: 不断向全局缓存添加数据
    console.log(`Added ${key} to cache. Cache size: ${Object.keys(globalCache).length}`);
});

document.getElementById('clearCache').addEventListener('click', () => {
    // BUG: 即使尝试清理，如果不是完全清空，或者清理策略有误，仍可能泄漏
    // globalCache = {}; // 这样会创建一个新对象，但旧的globalCache仍然可能被某个闭包捕获
    for (const key in globalCache) {
        delete globalCache[key]; // 尝试删除属性
    }
    console.log('Attempted to clear globalCache. Waiting for GC...');
});

追踪步骤：

基线快照： 加载 index.html 页面，点击 Take snapshot。
执行可疑操作： 反复点击 添加数据到缓存 按钮 5-10 次。
尝试清理： 点击 清理缓存 按钮。
强制垃圾回收： （可选）点击垃圾桶图标。
再次快照： 再次点击 Take snapshot。
比较快照： 选择第二个快照，与第一个快照比较。

分析结果：

在比较视图中，你会发现 Object、Array、(string) 等类型的 Delta Retained Size 持续增长。

Constructor	#New	#Delta	Delta Retained Size
Object	10	10	2 MB
Array	10	10	2 MB
(string)	10	10	200 KB
…	…	…	…

展开 Object，你会看到多个 (object) 条目。选中其中一个，在 Retainers 面板中，你会看到它被 globalCache 对象引用，而 globalCache 又被 (global property) 引用（即 window.globalCache）。这清晰地表明 globalCache 持续增长，并且由于它是全局可访问的，其内部的 generateLargeObject 实例也无法被回收。

解决方案：

对于全局缓存，必须有明确的失效策略，例如基于 LRU（最近最少使用）或 TTL（存活时间）的机制。或者，如果缓存的对象可以被弱引用，考虑使用 WeakMap。

// leak-cache-fixed.js
// 方案一：使用 WeakMap 作为缓存（如果缓存的key是对象且不需要遍历）
// const globalCache = new WeakMap();

// 方案二：使用普通对象，但实现清理机制
const globalCache = {}; 
const MAX_CACHE_SIZE = 5; // 示例：最大缓存项数

function generateLargeObject(id) {
    return {
        id: id,
        timestamp: Date.now(),
        data: new Array(200000).fill(`data for ${id}`)
    };
}

let counter = 0;
document.getElementById('addData').addEventListener('click', () => {
    const key = `item_${counter++}`;
    globalCache[key] = generateLargeObject(key); 

    // 关键修复：实现简单的清理策略
    const keys = Object.keys(globalCache);
    if (keys.length > MAX_CACHE_SIZE) {
        // 移除最旧的项
        const oldestKey = keys[0]; // 假设key的生成是递增的
        delete globalCache[oldestKey];
        console.log(`Cache overflow, removed ${oldestKey}`);
    }

    console.log(`Added ${key} to cache. Cache size: ${Object.keys(globalCache).length}`);
});

document.getElementById('clearCache').addEventListener('click', () => {
    for (const key in globalCache) {
        delete globalCache[key];
    }
    console.log('Cleared globalCache. Waiting for GC...');
});

验证： 替换代码后，重复上述追踪步骤。这次你会发现 Object、Array 相关的 Delta Retained Size 在达到一定数量后会稳定下来，不再持续增长。

进阶技巧与注意事项

强制垃圾回收 (window.gc())：
如前所述，window.gc() 并非在所有情况下都可用。你需要在启动 Chrome 时添加 --expose-gc 命令行参数。例如：
chrome.exe --expose-gc (Windows)
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --expose-gc (macOS)
这在调试环境中非常有用，可以确保在拍摄快照前尽可能地清理内存。
理解 GC Roots：
所有无法被回收的对象，最终都会有一条从 GC Root 到它的引用路径。GC Root 通常包括：
- 全局对象（window、global）
- 当前执行栈中的局部变量和参数
- 当前注册的事件监听器
- 活动中的定时器回调
- 被 WeakMap 或 WeakSet 以外的集合（Map、Set、Array、Object）引用的对象。
  在 Retainers 面板中，仔细分析引用链条，直到追溯到 GC Root，就能找到泄漏的根本原因。
使用 Allocation Instrumentation on Timeline：
如果你的问题是内存分配峰值过高，而不是持续增长，那么 Allocation instrumentation on timeline 会更有用。它能实时显示内存分配和回收的图表，并标记出在某个时间段内分配的对象。这有助于识别哪些操作导致了大量的临时对象创建。
注意 (string) 和 (array) 类型：
字符串和数组在 JavaScript 中是常见的数据结构。如果你的应用处理大量文本或数据，它们可能会成为内存泄漏的间接受害者。当你在快照中看到大量未被回收的 (string) 或 (array) 时，通常需要追踪它们的引用者，找出是哪个业务对象保留了它们。
隔离泄漏场景：
在复杂的应用中，一步到位找到泄漏源头是困难的。最好的方法是：
- 最小化重现路径： 找出触发泄漏的最小操作序列。
- 创建隔离测试页： 如果可能，创建一个只包含可疑组件或逻辑的独立页面进行测试。
- 逐个排查： 如果怀疑多个地方可能泄漏，可以逐个注释掉或修改可疑代码块，然后重复快照比较，以缩小范围。
警惕第三方库：
有时内存泄漏可能来自你使用的第三方库。如果排查了所有自己的代码都无果，可以尝试升级库版本，或者在怀疑的库函数调用前后拍摄快照。

预防内存泄漏的最佳实践

与其事后追踪，不如在开发过程中就养成良好的习惯，预防内存泄漏的发生：

及时解除引用： 当一个对象不再需要时，显式地将其引用设置为 null（尤其是在长生命周期的对象中，或者当变量可能捕获大闭包时）。
移除事件监听器： 凡是添加了事件监听器，就应该在组件销毁或不再需要时，移除对应的监听器。使用 addEventListener 对应的 removeEventListener。
清除定时器： 对于 setInterval 和 setTimeout，确保在不再需要时调用 clearInterval 或 clearTimeout。
谨慎使用全局变量： 尽量减少全局变量的使用。如果必须使用，确保其生命周期受控，并在不再需要时清理。
管理缓存： 实施有效的缓存策略，如 LRU、TTL，或者在适当的时候清理缓存。对于键是对象的缓存，优先考虑 WeakMap。
避免脱离 DOM 引用： 当从 DOM 中移除元素时，确保所有 JavaScript 代码中对这些元素的引用也一并清除。
理解闭包： 深入理解闭包的工作原理。避免在长期存在的闭包中意外捕获大对象。
使用 let 和 const 替代 var： let 和 const 具有块级作用域，有助于减少意外的全局变量和作用域污染。
关注生命周期： 在开发组件时，清晰定义其生命周期，并在销毁阶段执行必要的清理工作。

内存优化的持续旅程

内存泄漏是前端开发中一个复杂但可解决的问题。通过深入理解 JavaScript 的垃圾回收机制，并熟练运用 Chrome Memory Profile 中的堆快照比较功能，特别是关注 Retained Size，我们可以有效地定位并修复这些隐蔽的内存问题。这不仅能提升用户体验，也是衡量一个应用健壮性的重要指标。

记住，性能优化是一个持续的过程。通过定期进行内存分析，并在开发过程中遵循最佳实践，我们可以构建出更加高效和稳定的 Web 应用程序。

内存泄漏的本质：垃圾回收机制的盲点

常见的内存泄漏场景

Chrome Memory Profile：内存泄漏的侦查工具

启动 Memory Profile

深入理解堆快照（Heap Snapshot）

堆快照视图解读

Retained Size 的重要性

内存泄漏追踪实战：利用堆快照比较功能

追踪内存泄漏的通用步骤

比较视图解读

案例分析：寻找 Retained Size 的源头

案例一：脱离 DOM 树的 DOM 元素泄漏

案例二：闭包导致的大对象泄漏

案例三：未移除的事件监听器泄漏

案例四：全局变量或不当缓存导致泄漏

进阶技巧与注意事项

预防内存泄漏的最佳实践

内存优化的持续旅程

发表回复 取消回复

发表回复取消回复