JavaScript 메모리 누수의 4가지 방법과 이를 방지하는 방법 자세한 소개

이 기사에서는 일반적인 클라이언트 측 JavaScript 메모리 누수와 Chrome 개발자 도구를 사용하여 이를 찾는 방법을 살펴봅니다.

소개

메모리 누수는 모든 개발자가 결국 직면하게 되는 문제이며 느린 응답, 충돌, 높은 대기 시간 및 기타 애플리케이션 문제 등 많은 문제의 원인입니다.

메모리 누수란 무엇인가요?

기본적으로 메모리 누수는 다음과 같이 정의할 수 있습니다. 애플리케이션이 더 이상 메모리를 차지할 필요가 없어 어떤 이유로 운영 체제나 사용 가능한 메모리 풀에서 메모리를 회수하지 못하는 경우입니다. 프로그래밍 언어는 메모리를 관리하는 방법에 따라 다릅니다. 어떤 메모리가 더 이상 필요하지 않고 운영 체제에서 회수될 수 있는지는 개발자만이 가장 잘 알고 있습니다. 일부 프로그래밍 언어는 개발자가 이러한 작업을 수행하는 데 도움이 되는 언어 기능을 제공합니다. 다른 사람들은 메모리가 필요한지 여부를 명확히 하기 위해 개발자에게 의존합니다.

JavaScript 메모리 관리

JavaScript는 가비지 수집 언어입니다. 가비지 컬렉션 언어는 이전에 할당된 메모리에 접근할 수 있는지 주기적으로 확인하여 개발자가 메모리를 관리하는 데 도움을 줍니다. 즉, 가비지 콜렉션 언어는 "메모리는 여전히 사용 가능하다", "메모리는 여전히 접근 가능하다"는 문제를 완화시킨다. 둘 사이의 차이점은 미묘하지만 중요합니다. 개발자만이 앞으로 어떤 메모리가 사용될지 알 수 있지만, 연결할 수 없는 메모리는 알고리즘에 따라 결정 및 표시되며 운영 체제에서 즉시 회수됩니다.

JavaScript 메모리 누수

가비지 수집 언어에서 메모리 누수의 주요 원인은 원치 않는 참조입니다. 이를 이해하기 전에 가비지 수집 언어가 도달 가능한 메모리와 도달할 수 없는 메모리를 구별하는 방법을 이해해야 합니다.

Mark-and-sweep

대부분의 가비지 수집 언어에서 사용하는 알고리즘을 Mark-and-sweep이라고 합니다. 알고리즘은 다음 단계로 구성됩니다.

1. 가비지 수집기는 "루트" 목록을 생성합니다. 루트는 일반적으로 코드의 전역 변수에 대한 참조입니다. JavaScript에서 "window" 개체는 전역 변수이며 루트로 처리됩니다. 창 객체는 항상 존재하므로 가비지 수집기는 해당 객체와 모든 하위 객체가 존재하는지 확인할 수 있습니다(즉, 가비지가 아님).

2. 모든 루트가 검사되고 활성 상태로 표시됩니다(즉, 그렇지 않음). 쓰레기). 모든 하위 개체도 재귀적으로 확인됩니다. 루트에서 시작하는 모든 객체는 접근 가능하다면 가비지로 간주되지 않습니다.

3. 표시되지 않은 모든 메모리는 가비지로 처리되며, 이제 수집기는 메모리를 해제하여 운영 체제로 반환할 수 있습니다.

최신 가비지 수집기는 알고리즘이 개선되었지만 본질은 동일합니다. 도달 가능한 메모리가 표시되고 나머지는 가비지 수집됩니다.

불필요한 참조는 개발자가 메모리 참조가 더 이상 필요하지 않다는 것을 알고 있지만 어떤 이유로 활성 루트 트리에 여전히 남아 있음을 의미합니다. JavaScript에서 원치 않는 참조는 코드에 남아 더 이상 필요하지 않지만 해제되어야 하는 메모리 부분을 가리키는 변수입니다. 어떤 사람들은 이것이 개발자의 실수라고 생각합니다.

JavaScript에서 가장 흔히 발생하는 메모리 누수를 이해하려면 참조가 어떻게 쉽게 잊혀지는지 이해해야 합니다.

세 가지 유형의 일반적인 JavaScript 메모리 누수

1: 예기치 않은 전역 변수

JavaScript는 정의되지 않은 변수를 느슨한 방식으로 처리합니다. 정의되지 않은 변수는 전역 개체에 있습니다. 변하기 쉬운. 브라우저에서 전역 객체는 window 입니다.

function foo(arg) {
    bar = "this is a hidden global variable";
}

사실은

function foo(arg) {
    window.bar = "this is an explicit global variable";
}

함수 foo가 내부적으로 var를 사용하는 것을 잊어버렸고 실수로 전역 변수를 생성했다는 것입니다. 이 예에서는 무해한 간단한 문자열이 유출되지만 더 나쁜 상황도 있습니다.

this에 의해 또 다른 예상치 못한 전역 변수가 생성될 수 있습니다.

function foo() {
    this.variable = "potential accidental global";
}

// Foo 调用自己，this 指向了全局对象（window）
// 而不是 undefined
foo();

이 유형의 오류를 방지하려면 JavaScript 파일의 헤더에 'use strict'를 추가하세요. 예상치 못한 전역 변수를 방지하려면 JavaScript의 엄격 모드 구문 분석을 활성화하세요.

전역 변수 참고

예상치 못한 전역 변수에 대해 논의했지만 명시적 전역 변수에 의해 생성되는 가비지가 여전히 있습니다. (비어 있거나 재할당된 것으로 정의되지 않은 경우) 재활용이 불가능한 것으로 정의됩니다. 특히 전역 변수를 사용하여 많은 양의 정보를 임시로 저장하고 처리하는 경우에는 주의가 필요합니다. 대량의 데이터를 저장하기 위해 글로벌 변수를 사용해야 하는 경우 반드시 null로 설정하거나 사용 후 다시 정의하시기 바랍니다. 전역 변수와 관련된 메모리 소비 증가의 주요 원인 중 하나는 캐싱입니다. 데이터 캐싱은 재사용을 위한 것이며 캐시가 유용하려면 크기에 상한이 있어야 합니다. 메모리 소비량이 많으면 캐시된 콘텐츠를 회수할 수 없기 때문에 캐시가 상한을 위반하게 됩니다.

2: 잊어버린 타이머 또는 콜백 함수

JavaScript에서 setInterval를 사용하는 것은 매우 일반적입니다. 일반적인 코드 조각:

var someResource = getData();
setInterval(function() {
    var node = document.getElementById('Node');
    if(node) {
        // 处理 node 和 someResource
        node.innerHTML = JSON.stringify(someResource));
    }
}, 1000);

이 예제에서 설명하는 내용: 노드 또는 데이터와 연결된 타이머가 더 이상 필요하지 않고, node 개체를 삭제할 수 있으며, 전체 콜백 함수가 더 이상 필요하지 않습니다. 그러나 타이머 콜백 함수는 아직 재활용되지 않았습니다. (타이머가 멈출 때까지 재활용되지 않습니다.) 동시에 someResource 많은 양의 데이터가 저장되면 재활용이 불가능합니다.

对于观察者的例子，一旦它们不再需要（或者关联的对象变成不可达），明确地移除它们非常重要。老的 IE 6 是无法处理循环引用的。如今，即使没有明确移除它们，一旦观察者对象变成不可达，大部分浏览器是可以回收观察者处理函数的。

观察者代码示例：

var element = document.getElementById('button');
function onClick(event) {
    element.innerHTML = 'text';
}

element.addEventListener('click', onClick);

对象观察者和循环引用注意事项

老版本的 IE 是无法检测 DOM 节点与 JavaScript 代码之间的循环引用，会导致内存泄露。如今，现代的浏览器（包括 IE 和 Microsoft Edge）使用了更先进的垃圾回收算法，已经可以正确检测和处理循环引用了。换言之，回收节点内存时，不必非要调用 removeEventListener 了。

3：脱离 DOM 的引用

有时，保存 DOM 节点内部数据结构很有用。假如你想快速更新表格的几行内容，把每一行 DOM 存成字典（JSON 键值对）或者数组很有意义。此时，同样的 DOM 元素存在两个引用：一个在 DOM 树中，另一个在字典中。将来你决定删除这些行时，需要把两个引用都清除。

var elements = {
    button: document.getElementById('button'),
    image: document.getElementById('image'),
    text: document.getElementById('text')
};

function doStuff() {
    image.src = 'http://some.url/image';
    button.click();
    console.log(text.innerHTML);
    // 更多逻辑
}

function removeButton() {
    // 按钮是 body 的后代元素
    document.body.removeChild(document.getElementById('button'));

    // 此时，仍旧存在一个全局的 #button 的引用
    // elements 字典。button 元素仍旧在内存中，不能被 GC 回收。
}

此外还要考虑 DOM 树内部或子节点的引用问题。假如你的 JavaScript 代码中保存了表格某一个 <td> 的引用。将来决定删除整个表格的时候，直觉认为 GC 会回收除了已保存的 <code><td> 以外的其它节点。实际情况并非如此：此<code><td> 是表格的子节点，子元素与父元素是引用关系。由于代码保留了 <code><td> 的引用，导致整个表格仍待在内存中。保存 DOM 元素引用的时候，要小心谨慎。<h2>4：<span class="wp_keywordlink">闭包</span> </h2> <p>闭包是 JavaScript 开发的一个关键方面：匿名函数可以访问父级作用域的变量。</p> <p>代码示例：</p><pre class="brush:js;toolbar:false;">var theThing = null; var replaceThing = function () { var originalThing = theThing; var unused = function () { if (originalThing) console.log(&quot;hi&quot;); }; theThing = { longStr: new Array(1000000).join(&amp;#39;*&amp;#39;), someMethod: function () { console.log(someMessage); } }; }; setInterval(replaceThing, 1000);</pre><p>代码片段做了一件事情：每次调用 <code>replaceThing ，theThing 得到一个包含一个大数组和一个新闭包（someMethod）的新对象。同时，变量 unused 是一个引用 originalThing 的闭包（先前的 replaceThing 又调用了 theThing ）。思绪混乱了吗？最重要的事情是，闭包的作用域一旦创建，它们有同样的父级作用域，作用域是共享的。someMethod 可以通过 theThing 使用，someMethod 与 unused 分享闭包作用域，尽管 unused从未使用，它引用的 originalThing 迫使它保留在内存中（防止被回收）。当这段代码反复运行，就会看到内存占用不断上升，垃圾回收器（GC）并无法降低内存占用。本质上，闭包的链表已经创建，每一个闭包作用域携带一个指向大数组的间接的引用，造成严重的内存泄露。

Meteor 的博文 解释了如何修复此种问题。在 replaceThing 的最后添加 originalThing = null 。

Chrome 内存剖析工具概览

Chrome 提供了一套很棒的检测 JavaScript 内存占用的工具。与内存相关的两个重要的工具：timeline 和 profiles。

Timeline

timeline 可以检测代码中不需要的内存。在此截图中，我们可以看到潜在的泄露对象稳定的增长，数据采集快结束时，内存占用明显高于采集初期，Node（节点）的总量也很高。种种迹象表明，代码中存在 DOM 节点泄露的情况。

Profiles

Profiles 是你可以花费大量时间关注的工具，它可以保存快照，对比 JavaScript 代码内存使用的不同快照，也可以记录时间分配。每一次结果包含不同类型的列表，与内存泄露相关的有 summary（概要） 列表和 comparison（对照） 列表。

summary（概要） 列表展示了不同类型对象的分配及合计大小：shallow size（特定类型的所有对象的总大小），retained size（shallow size 加上其它与此关联的对象大小）。它还提供了一个概念，一个对象与关联的 GC root 的距离。

对比不同的快照的 comparison list 可以发现内存泄露。

实例：使用 Chrome 发现内存泄露

实质上有两种类型的泄露：周期性的内存增长导致的泄露，以及偶现的内存泄露。显而易见，周期性的内存泄露很容易发现；偶现的泄露比较棘手，一般容易被忽视，偶尔发生一次可能被认为是优化问题，周期性发生的则被认为是必须解决的 bug。

以 Chrome 文档中的代码为例：

var x = [];

function createSomeNodes() {
    var p,
        i = 100,
        frag = document.createDocumentFragment();

    for (;i > 0; i--) {
        p = document.createElement("p");
        p.appendChild(document.createTextNode(i + " - "+ new Date().toTimeString()));
        frag.appendChild(p);
    }

    document.getElementById("nodes").appendChild(frag);
}

function grow() {
    x.push(new Array(1000000).join('x'));
    createSomeNodes();
    setTimeout(grow,1000);
}

当 grow 执行的时候，开始创建 p 节点并插入到 DOM 中，并且给全局变量分配一个巨大的数组。通过以上提到的工具可以检测到内存稳定上升。

找出周期性增长的内存

timeline 标签擅长做这些。在 Chrome 中打开例子，打开 Dev Tools ，切换到 timeline，勾选 memory 并点击记录按钮，然后点击页面上的 The Button 按钮。过一阵停止记录看结果：

两种迹象显示出现了内存泄露，图中的 Nodes（绿线）和 JS heap（蓝线）。Nodes 稳定增长，并未下降，这是个显著的信号。

JS heap 的内存占用也是稳定增长。由于垃圾收集器的影响，并不那么容易发现。图中显示内存占用忽涨忽跌，实际上每一次下跌之后，JS heap 的大小都比原先大了。换言之，尽管垃圾收集器不断的收集内存，内存还是周期性的泄露了。

确定存在内存泄露之后，我们找找根源所在。

保存两个快照

切换到 Chrome Dev Tools 的 profiles 标签，刷新页面，等页面刷新完成之后，点击 Take Heap Snapshot 保存快照作为基准。而后再次点击 The Button 按钮，等数秒以后，保存第二个快照。

筛选菜单选择 Summary，右侧选择 Objects allocated between Snapshot 1 and Snapshot 2，或者筛选菜单选择 Comparison ，然后可以看到一个对比列表。

此例很容易找到内存泄露，看下 (string) 的 Size Delta Constructor，8MB，58个新对象。新对象被分配，但是没有释放，占用了8MB。

如果展开 (string) Constructor，会看到许多单独的内存分配。选择某一个单独的分配，下面的 retainers 会吸引我们的注意。

我们已选择的分配是数组的一部分，数组关联到 window 对象的 x 变量。这里展示了从巨大对象到无法回收的 root（window）的完整路径。我们已经找到了潜在的泄露以及它的出处。

我们的例子还算简单，只泄露了少量的 DOM 节点，利用以上提到的快照很容易发现。对于更大型的网站，Chrome 还提供了 Record Heap Allocations 功能。

Record heap allocations 找内存泄露

回到 Chrome Dev Tools 的 profiles 标签，点击 Record Heap Allocations。工具运行的时候，注意顶部的蓝条，代表了内存分配，每一秒有大量的内存分配。运行几秒以后停止。

上图中可以看到工具的杀手锏：选择某一条时间线，可以看到这个时间段的内存分配情况。尽可能选择接近峰值的时间线，下面的列表仅显示了三种 constructor：其一是泄露最严重的（string），下一个是关联的 DOM 分配，最后一个是 Text constructor（DOM 叶子节点包含的文本）。

从列表中选择一个 HTMLpElement constructor，然后选择 Allocation stack。

现在知道元素被分配到哪里了吧（grow -> createSomeNodes），仔细观察一下图中的时间线，发现 HTMLpElement constructor 调用了许多次，意味着内存一直被占用，无法被 GC 回收，我们知道了这些对象被分配的确切位置（createSomeNodes）。回到代码本身，探讨下如何修复内存泄露吧。

另一个有用的特性

在 heap allocations 的结果区域，选择 Allocation。

이 뷰에서는 grow과 createSomeNodes이 바로 보입니다. grow을 선택하면 해당 객체 생성자를 보면 (string), HTMLpElement, Text이 유출된 것이 분명합니다.

위에서 언급한 도구와 결합하면 메모리 누수를 쉽게 찾을 수 있습니다.

위에는 자바스크립트 메모리 누수의 4가지 방법과 이를 방지하는 방법에 대한 자세한 내용이 있으니 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!