JS `Memory Snapshots` `Retaining Paths` 分析：识别复杂引用链导致的内存泄漏

各位老铁，早上好！今天咱们聊聊JS里让人头疼的“内存泄漏”以及如何用Chrome DevTools的“Memory Snapshots”里的“Retaining Paths”揪出背后的“黑手”。

内存泄漏就像你家的水龙头，一直滴滴答答，不关紧。刚开始你可能没啥感觉，但时间长了，水池子溢出来了，房子也淹了。JS里的内存泄漏也是一样，少量泄漏可能察觉不到，但积累多了，浏览器就卡顿了，甚至崩溃了。

内存泄漏的那些事儿

简单来说，内存泄漏就是程序不再需要使用的内存，却仍然被占用，导致可用内存越来越少。JS作为一种垃圾回收(Garbage Collection, GC)的语言，按理说应该自动管理内存。但是，总有一些情况，GC “手滑” 了，没能正确回收那些应该回收的内存。

常见的内存泄漏场景

意外的全局变量： 在非严格模式下，你可能会不小心创建一个全局变量，比如：
```
function foo(arg) {
  bar = "这是一段很长的字符串"; // 忘记加var/let/const，bar变成全局变量
}

foo(); // 调用后，bar就一直存在于全局作用域，不会被回收
```
这个bar变量会一直存在于全局作用域，直到页面关闭，它占用的内存也就一直不会被释放。

闭包引起的内存泄漏： 闭包会保存对外部变量的引用。如果这个外部变量是一个很大的对象，而闭包又一直存在，那么这个对象就无法被回收。

function outer() {
  let hugeObject = { data: new Array(1000000).fill(1) }; // 一个很大的对象

  return function inner() {
    console.log(hugeObject.data[0]); // inner函数引用了hugeObject
  };
}

let theClosure = outer(); // 创建闭包
// ... 一段时间后，我们不再需要theClosure了，但是它仍然存在
theClosure(); // 证明它还能用
// 如果没有手动解除引用，hugeObject就无法被回收
// theClosure = null; // 手动解除引用

在这个例子中，即使我们不再使用theClosure，它仍然保持对hugeObject的引用，导致hugeObject无法被垃圾回收。

被遗忘的定时器和回调函数： 如果你设置了一个定时器，或者注册了一个事件监听器，但忘记清除它们，那么相关的回调函数和它们引用的变量也会一直存在。

let element = document.getElementById('myButton');
let hugeObject = { data: new Array(1000000).fill(1) };

function onClick() {
  console.log('Button clicked!', hugeObject.data[0]);
}

element.addEventListener('click', onClick);

// 如果不再需要这个按钮，应该移除事件监听器
// element.removeEventListener('click', onClick);
// element = null; // 也要手动移除element的引用，否则可能造成DOM泄漏

在这个例子中，即使element从DOM中移除，onClick函数仍然会保持对hugeObject的引用，导致hugeObject无法被回收。

DOM 节点的循环引用: 如果两个 DOM 节点互相引用，并且没有被正确地从 DOM 树中移除，那么即使在 JavaScript 代码中不再引用它们，它们也可能无法被垃圾回收。

<!DOCTYPE html>
<html>
<head>
    <title>DOM循环引用示例</title>
</head>
<body>
    <div id="container">
        <div id="element1">Element 1</div>
        <div id="element2">Element 2</div>
    </div>

    <script>
        const element1 = document.getElementById('element1');
        const element2 = document.getElementById('element2');
        const container = document.getElementById('container');

        // 创建循环引用
        element1.circularReference = element2;
        element2.circularReference = element1;

        // 移除 container，但循环引用仍然存在
        container.remove();
        //container = null;

        // 在实际情况下，即使 container 被移除，由于 element1 和 element2 互相引用，
        // 它们仍然可能无法被垃圾回收，导致内存泄漏。

        // 为了避免这种情况，你应该在移除 container 之前解除循环引用：
        // element1.circularReference = null;
        // element2.circularReference = null;
        // container.remove();
        // container = null;
    </script>
</body>
</html>

控制台日志： 某些浏览器（尤其是老版本）的控制台会保持对打印对象的引用，导致它们无法被回收。
```
let hugeObject = { data: new Array(1000000).fill(1) };
console.log(hugeObject); // 控制台可能会保持对hugeObject的引用
hugeObject = null; // 即使手动设置为null，也可能无法被回收
```
在开发过程中，要尽量避免在生产环境的代码中留下过多的console.log语句。
第三方库的bug： 有时候，内存泄漏可能是由于你使用的第三方库存在bug导致的。

Chrome DevTools Memory Snapshots 登场

Chrome DevTools的Memory面板可以帮助我们分析内存使用情况。其中，Memory Snapshots功能可以让我们拍摄内存快照，然后比较不同快照之间的差异，找出内存泄漏的“嫌疑人”。

如何使用 Memory Snapshots

打开 Chrome DevTools： 在 Chrome 浏览器中，按下 F12 或者 Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac) 打开开发者工具。
切换到 Memory 面板： 在开发者工具中，点击 "Memory" 选项卡。
选择 Heap snapshot： 在左侧的面板中，确保选择 "Heap snapshot" 选项。
拍摄快照： 点击左侧的圆形按钮（Take heap snapshot）拍摄第一个快照。
执行一些操作： 执行你怀疑会导致内存泄漏的操作。
再次拍摄快照： 再次点击圆形按钮拍摄第二个快照。
比较快照： 在快照列表中，选择第二个快照，然后在下拉菜单中选择 "Comparison" 模式，并选择第一个快照进行比较。

快照视图的解读

拍摄快照后，你会看到一个表格，其中包含各种对象的统计信息。

Constructor: 对象的构造函数名称。
Size: 对象占用的内存大小（字节）。
Shallow Size: 对象自身占用的内存大小，不包括它引用的其他对象。
Retained Size: 对象自身占用的内存大小加上它直接或间接引用的所有其他对象的大小。这个值最能反映对象对内存的影响。
Distance: 从 GC 根节点到该对象的最短距离。距离越长，说明该对象越有可能被垃圾回收。

利用 Retaining Paths 找到“黑手”

光看这些统计信息还不够，我们需要找到导致内存泄漏的“引用链”。这就是 "Retaining Paths" 的作用。

当你发现某个对象的 Retained Size 异常大时，可以点击它，然后在下方的 "Retainers" 面板中查看它的 Retaining Paths。Retaining Paths 显示了从 GC 根节点到该对象的引用链。

Retaining Paths 就像侦探小说里的线索，一步步引导你找到真正的凶手。

案例分析：闭包引起的内存泄漏

我们用一个简单的例子来演示如何使用 Retaining Paths 找到闭包引起的内存泄漏。

<!DOCTYPE html>
<html>
<head>
  <title>Closure Memory Leak Example</title>
</head>
<body>
  <button id="myButton">Click Me</button>
  <script>
    let myButton = document.getElementById('myButton');
    let hugeObject = { data: new Array(1000000).fill(1) };

    function createClosure() {
      let localHugeObject = hugeObject; // 故意引入一个局部变量，增加复杂性
      myButton.addEventListener('click', function() {
        console.log(localHugeObject.data[0]); // 闭包引用了localHugeObject
      });
    }

    createClosure();
    // myButton = null; // 即使手动设置为null，监听器依然存在
    // 如果没有移除监听器，hugeObject就无法被回收
    // myButton.removeEventListener('click', theClosure);
  </script>
</body>
</html>

打开页面，拍摄第一个快照。
点击按钮几次，模拟用户交互。
拍摄第二个快照。
在第二个快照中，选择 "Comparison" 模式，并与第一个快照进行比较。
在 Constructor 列中，找到 "Object" （或者根据你的实际情况，找到你怀疑泄漏的对象）。
关注 Retained Size 列，找到 Retained Size 增长最多的对象。 很有可能这个对象就是 hugeObject。
点击这个对象，在下方的 "Retainers" 面板中查看 Retaining Paths。

你会看到类似这样的引用链：

-> Window
  -> document
    -> <button id="myButton">
      -> EventListenerList
        -> [0]: listener: function() { ... }
          -> Closure (createClosure)
            -> localHugeObject: {data: Array(1000000)}
              -> data: Array(1000000)
                -> (Array elements)

这条引用链告诉我们：

hugeObject 被 localHugeObject 引用。
localHugeObject 被 createClosure 函数创建的闭包引用。
这个闭包被 myButton 的事件监听器列表引用。
myButton 被 document 引用。
document 被 Window 引用。
Window 是 GC 根节点，永远不会被回收。

真相大白了！ 闭包保持了对 localHugeObject 的引用，而 localHugeObject 又引用了 hugeObject，导致 hugeObject 无法被回收。

如何解决这个问题？

在不再需要这个按钮时，移除事件监听器：

myButton.removeEventListener('click', theClosure); // 假设theClosure是监听函数
myButton = null; // 也要手动移除element的引用，否则可能造成DOM泄漏

高级技巧

构造函数过滤： 在快照视图中，可以使用过滤器只显示特定构造函数的对象，例如 "Array"、"Object" 等。
对象ID搜索： 如果你知道某个对象的ID，可以使用搜索功能快速找到它。
多次快照对比： 可以拍摄多个快照，然后比较它们之间的差异，更精确地定位内存泄漏。
结合 Timeline 和 Profiles： Memory Snapshots 可以和 Timeline (Performance) 和 Profiles 面板结合使用，更全面地分析性能问题。

表格总结

问题类型	原因	如何排查	解决方案
意外的全局变量	忘记使用 `var`/`let`/`const` 声明变量	Memory Snapshots -> 查找全局作用域下的变量 -> Retaining Paths	使用 `var`/`let`/`const` 正确声明变量
闭包引起的内存泄漏	闭包引用了外部的大对象，且闭包一直存在	Memory Snapshots -> 查找闭包 -> Retaining Paths -> 找到被闭包引用的对象	确保在不再需要闭包时，解除对外部对象的引用
定时器/回调函数	定时器/回调函数没有被正确清除	Memory Snapshots -> 查找定时器/回调函数 -> Retaining Paths -> 找到被定时器/回调函数引用的对象	在不再需要定时器/回调函数时，清除它们
DOM循环引用	DOM节点互相引用，且没有从DOM树中移除	Memory Snapshots -> 查找DOM节点 -> Retaining Paths -> 确认是否存在循环引用	在移除DOM节点之前，解除循环引用
控制台日志	控制台保持了对打印对象的引用	尽量避免在生产环境留下过多的 `console.log` 语句	在生产环境中移除不必要的 `console.log` 语句
第三方库bug	第三方库存在内存泄漏bug	升级第三方库版本，或者寻找替代方案	及时更新依赖库，或者寻找替代库

总结

内存泄漏是JS开发中常见的问题，但通过Chrome DevTools的Memory Snapshots和Retaining Paths，我们可以像侦探一样，一步步找到“黑手”，解决内存泄漏问题，提升应用的性能和稳定性。

记住，预防胜于治疗。在开发过程中，要注意避免常见的内存泄漏场景，编写高质量的代码。

好了，今天的讲座就到这里。希望对大家有所帮助！如果大家还有其他问题，可以在评论区留言。下次再见！