4 Arten von JavaScript-Speicherlecks und wie man sie vermeidet-js-Tutorial-php.cn

Originaltext: 4 Arten von Speicherlecks in JavaScript und wie man sie beseitigt

Übersetzung aus: Alons Blog

In diesem Artikel wird der gängige clientseitige JavaScript-Speicher untersucht Lecks und wie man Chrome Dev Tools verwendet, um Probleme zu finden.

Einführung
Speicherlecks sind ein Problem, mit dem jeder Entwickler irgendwann konfrontiert wird, und sie sind die Ursache vieler Probleme: langsame Reaktion, Abstürze, hohe Latenz und andere Anwendungsprobleme.

Was ist ein Speicherverlust?
Im Wesentlichen kann ein Speicherverlust wie folgt definiert werden: Wenn die Anwendung den Speicher aus irgendeinem Grund nicht mehr belegen muss, wird der Speicher nicht vom Betriebssystem oder dem verfügbaren Speicherpool zurückgefordert. Programmiersprachen unterscheiden sich in der Art und Weise, wie sie den Speicher verwalten. Nur Entwickler wissen am besten, welcher Speicher nicht mehr benötigt wird und vom Betriebssystem zurückgefordert werden kann. Einige Programmiersprachen bieten Sprachfunktionen, die Entwicklern dabei helfen, solche Dinge zu tun. Andere verlassen sich darauf, dass Entwickler sich darüber im Klaren sind, ob Speicher benötigt wird.

JavaScript-Speicherverwaltung
JavaScript ist eine Garbage-Collection-Sprache. Garbage-Collection-Sprachen helfen Entwicklern bei der Speicherverwaltung, indem sie regelmäßig prüfen, ob zuvor zugewiesener Speicher erreichbar ist. Mit anderen Worten, durch Müll gesammelte Sprachen lindern die Probleme „Speicher ist noch verfügbar“ und „Speicher ist noch erreichbar“. Der Unterschied zwischen den beiden ist subtil, aber wichtig: Nur der Entwickler weiß, welcher Speicher in Zukunft noch verwendet wird, während nicht erreichbarer Speicher algorithmisch ermittelt und markiert wird und vom Betriebssystem umgehend zurückgefordert wird.

JavaScript-Speicherlecks
Die Hauptursache für Speicherlecks in Garbage-Collected-Sprachen sind unerwünschte Verweise. Bevor Sie es verstehen, müssen Sie verstehen, wie die Garbage-Collection-Sprache zwischen erreichbarem und nicht erreichbarem Speicher unterscheidet.

Mark-and-Sweep
Der von den meisten Garbage-Collection-Sprachen verwendete Algorithmus heißt Mark-and-Sweep. Der Algorithmus besteht aus den folgenden Schritten:

1. Der Garbage Collector erstellt eine „Roots“-Liste. Wurzeln sind normalerweise Verweise auf globale Variablen in Ihrem Code. In JavaScript ist das „window“-Objekt eine globale Variable und wird als Root behandelt. Das Fensterobjekt ist immer vorhanden, sodass der Garbage Collector überprüfen kann, ob es und alle seine Unterobjekte vorhanden sind (d. h. kein Müll sind).
2. Alle Unterobjekte werden ebenfalls rekursiv überprüft. Wenn alle Objekte ab Root erreichbar sind, gelten sie nicht als Müll.
3. Der gesamte nicht markierte Speicher wird als Müll behandelt. Der Collector kann den Speicher nun freigeben und an das Betriebssystem zurückgeben.
Moderne Garbage Collectors verfügen über verbesserte Algorithmen, aber das Wesentliche ist dasselbe: Der erreichbare Speicher wird markiert und der Rest wird durch Garbage Collection gesammelt.

Unnötige Referenz bedeutet, dass der Entwickler weiß, dass die Speicherreferenz nicht mehr benötigt wird, sie aber aus irgendeinem Grund immer noch im aktiven Stammbaum verbleibt. In JavaScript ist eine unerwünschte Referenz eine Variable, die im Code verbleibt und nicht mehr benötigt wird, aber auf einen Speicherbereich verweist, der freigegeben werden sollte. Einige Leute denken, dass dies ein Entwicklerfehler ist.

Um die häufigsten Speicherlecks in JavaScript zu verstehen, müssen wir verstehen, wie Referenzen leicht vergessen werden.

Drei Arten häufiger JavaScript-Speicherlecks
1: Unerwartete globale Variablen
JavaScript behandelt undefinierte Variablen locker: undefiniert Die Variable wird erstellt eine neue Variable im globalen Objekt. In Browsern ist das globale Objekt window .

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

Nach dem Login kopieren

Die Wahrheit ist:

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

Nach dem Login kopieren

Ich habe vergessen, var intern in der Funktion foo zu verwenden, und versehentlich eine globale Variable erstellt. Dieses Beispiel lässt eine einfache Zeichenfolge durchsickern, was harmlos ist, aber es gibt schlimmere Dinge.

Eine weitere unerwartete globale Variable kann dadurch erstellt werden:

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

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

Nach dem Login kopieren

Referenziert durch

beim Hinzufügen Durch die Verwendung von „strikt verwenden“ für den Header von JavaScript-Dateien können solche Fehler vermieden werden. Aktivieren Sie das Parsen von JavaScript im strikten Modus, um unerwartete globale Variablen zu vermeiden.

Anmerkungen zu globalen Variablen

Obwohl wir einige unerwartete globale Variablen besprochen haben, gibt es immer noch Müll, der durch explizite globale Variablen generiert wird. Sie gelten als nicht recycelbar (sofern sie nicht als leer oder neu zugewiesen definiert sind). Besondere Vorsicht ist geboten, wenn globale Variablen zur temporären Speicherung und Verarbeitung großer Informationsmengen verwendet werden. Wenn Sie eine globale Variable zum Speichern einer großen Datenmenge verwenden müssen, stellen Sie sicher, dass Sie sie nach der Verwendung auf Null setzen oder neu definieren. Eine Hauptursache für den erhöhten Speicherverbrauch im Zusammenhang mit globalen Variablen ist das Caching. Das Zwischenspeichern von Daten dient der Wiederverwendung und der Cache muss eine Obergrenze für seine Größe haben, um nützlich zu sein. Ein hoher Speicherverbrauch führt dazu, dass der Cache seine Obergrenze überschreitet, da zwischengespeicherte Inhalte nicht wiederhergestellt werden können.

2: Der vergessene Timer oder die Callback-Funktion
Die Verwendung von setInterval in JavaScript ist sehr verbreitet. Ein häufiger Code:

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

Nach dem Login kopieren

此例说明了什么：与节点或数据关联的计时器不再需要，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);

Nach dem Login kopieren

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

老版本的 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 回收。
}

Nach dem Login kopieren

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

Nach dem Login kopieren

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

引用

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

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