ホームページ > 記事 > ウェブフロントエンド > JavaScript の 4 種類のメモリリークとその回避方法

JavaScript の 4 種類のメモリリークとその回避方法

黄舟オリジナル: 2017-02-23 13:32:131070ブラウズ

原文: 4 Types of Memory Leaks in JavaScript and How to Get Rid Of Them

翻訳元: Alon's Blog

この記事では、一般的なクライアントサイド JavaScript のメモリリークと、Chrome 開発ツールを使用して問題を見つける方法について説明します。

はじめに
メモリリークは、すべての開発者が最終的に直面する問題であり、応答の遅さ、クラッシュ、長い遅延、その他のアプリケーションの問題など、多くの問題の原因となります。

メモリリークとは何ですか?
基本的に、メモリリークは次のように定義できます。アプリケーションがメモリを占有する必要がなくなったときに、何らかの理由でメモリがオペレーティングシステムまたは利用可能なメモリプールによって再利用されないことです。プログラミング言語によってメモリの管理方法が異なります。どのメモリが不要になり、オペレーティングシステムによって再利用できるかは、開発者だけが最もよく知っています。一部のプログラミング言語は、開発者がこの種のことを行うのに役立つ言語機能を提供します。メモリが必要かどうかを開発者に明確にしてもらうことに依存している人もいます。

JavaScript メモリ管理
JavaScript はガベージコレクション言語です。ガベージコレクション言語は、以前に割り当てられたメモリが到達可能かどうかを定期的にチェックすることで、開発者がメモリを管理するのに役立ちます。言い換えれば、ガベージコレクション言語は、「メモリがまだ利用可能である」および「メモリがまだ到達可能である」問題を軽減します。 2 つの違いは微妙ですが重要です。どのメモリが今後も使用されるかは開発者だけが知っていますが、到達不能なメモリはアルゴリズムによって決定およびマークされ、オペレーティングシステムによって即座に回収されます。

JavaScript のメモリリーク
ガベージコレクション言語におけるメモリリークの主な原因は、不要な参照です。それを理解する前に、ガベージコレクション言語が到達可能なメモリと到達不可能なメモリをどのように区別するかを理解する必要があります。

マークアンドスイープ
ほとんどのガベージコレクション言語で使用されるアルゴリズムは、マークアンドスイープと呼ばれます。アルゴリズムは次のステップで構成されます:

1. ガベージコレクターは「ルート」リストを作成します。ルートは通常、コード内のグローバル変数への参照です。 JavaScript では、「ウィンドウ」オブジェクトはグローバル変数であり、ルートとして扱われます。 window オブジェクトは常に存在するため、ガベージコレクターはそれとそのすべての子オブジェクトが存在するかどうかを確認できます (つまり、ガベージではない)
2. すべてのルートがチェックされ、アクティブとしてマークされます (つまり、ガベージではない)。すべてのサブオブジェクトも再帰的にチェックされます。ルートから始まるすべてのオブジェクトが到達可能であれば、ガベージとはみなされません。
3. マークされていないメモリはすべてガベージとして扱われるようになり、コレクタはメモリを解放してオペレーティングシステムに返すことができます。
最新のガベージコレクターはアルゴリズムが改良されていますが、本質は同じです。到達可能なメモリにはマークが付けられ、残りはガベージコレクションされます。

不必要な参照とは、メモリ参照がもう必要ないことを開発者が認識しているにもかかわらず、何らかの理由でメモリ参照がアクティブなルートツリーにまだ残っていることを意味します。 JavaScript では、不要な参照とは、コード内に残り、不要になったが、解放される必要があるメモリの一部を指している変数です。これは開発者のミスだと考える人もいます。

JavaScript で最も一般的なメモリリークを理解するには、参照がどのように忘れられやすいかを理解する必要があります。

よくある 3 つのタイプの 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 を使用するのを忘れて、誤ってグローバル変数を作成してしまいました。この例では単純な文字列がリークされており、これは無害ですが、さらに悪いことがあります。

これによって別の予期しないグローバル変数が作成される可能性があります:

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

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

Quote

このようなエラーを避けるために、JavaScript ファイルの先頭に 'use strict' を追加します。 JavaScript の厳密モード解析を有効にして、予期しないグローバル変数を回避します。

グローバル変数に関するメモ

いくつかの予期せぬグローバル変数について説明しましたが、明示的なグローバル変数によって生成されるガベージがまだいくつかあります。これらは、(空または再割り当てとして定義されていない限り) リサイクル不可として定義されます。大量の情報を一時的に保存および処理するためにグローバル変数を使用する場合は特に注意が必要です。大量のデータを保存するためにグローバル変数を使用する必要がある場合は、必ず null に設定するか、使用後に再定義してください。グローバル変数に関連するメモリ消費量増加の主な原因の 1 つはキャッシュです。データのキャッシュは再利用するためのものであり、有効に使用するにはキャッシュのサイズに上限を設ける必要があります。メモリ消費量が多いと、キャッシュされたコンテンツを再利用できないため、キャッシュが上限を超えてしまいます。

2: 忘れられたタイマーまたはコールバック関数
JavaScript で setInterval を使用することは非常に一般的です。共通コード:

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

此例说明了什么：与节点或数据关联的计时器不再需要，node 对象可以删除，整个回调函数也不需要了。可是，计时器回调函数仍然没被回收（计时器停止才会被回收）。同时，someResource 如果存储了大量的数据，也是无法被回收的。

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

观察者代码示例：

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

element.addEventListener(&#39;click&#39;, onClick);

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

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

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

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

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

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

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

此外还要考虑 DOM 树内部或子节点的引用问题。假如你的 JavaScript 代码中保存了表格某一个 b6c5a531a458a2e790c1fd6421739d1c 的引用。将来决定删除整个表格的时候，直觉认为 GC 会回收除了已保存的 b6c5a531a458a2e790c1fd6421739d1c 以外的其它节点。实际情况并非如此：此 b6c5a531a458a2e790c1fd6421739d1c 是表格的子节点，子元素与父元素是引用关系。由于代码保留了 b6c5a531a458a2e790c1fd6421739d1c 的引用，导致整个表格仍待在内存中。保存 DOM 元素引用的时候，要小心谨慎。

4：闭包
闭包是JavaScript开发的一个关键方面：匿名函数可以访问父级作用域的变量。

代码示例：

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  var unused = function () {
    if (originalThing)
      console.log("hi");
  };

  theThing = {
    longStr: new Array(1000000).join(&#39;*&#39;),
    someMethod: function () {
      console.log(someMessage);
    }
  };
};

setInterval(replaceThing, 1000);

代码片段做了一件事情：每次调用 replaceThing ，theThing 得到一个包含一个大数组和一个新闭包（someMethod）的新对象。同时，变量 unused 是一个引用 originalThing 的闭包（先前的 replaceThing 又调用了 theThing ）。思绪混乱了吗？最重要的事情是，闭包的作用域一旦创建，它们有同样的父级作用域，作用域是共享的。someMethod 可以通过 theThing 使用，someMethod 与 unused 分享闭包作用域，尽管 unused 从未使用，它引用的 originalThing 迫使它保留在内存中（防止被回收）。当这段代码反复运行，就会看到内存占用不断上升，垃圾回收器（GC）并无法降低内存占用。本质上，闭包的链表已经创建，每一个闭包作用域携带一个指向大数组的间接的引用，造成严重的内存泄露。

引用

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

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