Wie man mit Javascript-Speicherlecks umgeht

Verarbeitungsmethode: 1. Weisen Sie nach der Verwendung Null zu oder weisen Sie andere Werte neu zu. 3. Seien Sie beim Speichern von DOM-Elementreferenzen vorsichtig. 4. Spielen Sie die Anwendung über SessionStack ab, um Speicherverluste zu vermeiden Erhöhen Sie die Speichernutzung der gesamten Anwendung.

Die Betriebsumgebung dieses Tutorials: Windows 7-System, JavaScript-Version 1.8.5, Dell G3-Computer. ,

Speicherlecks sind ein Problem, mit dem jeder Entwickler irgendwann konfrontiert wird. 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-Collected-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-Speicherleck

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 folgenden Schritten:

• Der Garbage Collector erstellt eine Liste von „Wurzeln“. 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 untergeordneten Objekte vorhanden sind (d. h. kein Müll sind). Alle Unterobjekte werden ebenfalls rekursiv überprüft. Alle Objekte, die im Stammverzeichnis beginnen, gelten nicht als Müll, wenn sie erreichbar sind.

• Der gesamte nicht markierte Speicher wird als Müll behandelt und 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 von häufigen JavaScript-Speicherlecks

1: Unerwartete globale Variablen

JavaScript behandelt undefinierte Variablen locker: Undefinierte Variablen erstellen eine neue Variable im globalen Objekt. In Browsern ist das globale Objekt window . Die Wahrheit ist:

Die Funktion foo hat vergessen, var intern zu verwenden und versehentlich eine globale Variable erstellt. Dieses Beispiel lässt eine einfache Zeichenfolge durchsickern, was harmlos ist, aber es gibt schlimmere Dinge. window 。

真相是：

函数 foo 内部忘记使用 var ，意外创建了一个全局变量。此例泄露了一个简单的字符串，无伤大雅，但是有更糟的情况。

另一种意外的全局变量可能由 this 创建：

在 JavaScript 文件头部加上 'use strict'，可以避免此类错误发生。启用严格模式解析 JavaScript ，避免意外的全局变量。

全局变量注意事项

尽管我们讨论了一些意外的全局变量，但是仍有一些明确的全局变量产生的垃圾。它们被定义为不可回收（除非定义为空或重新分配）。尤其当全局变量用于临时存储和处理大量信息时，需要多加小心。如果必须使用全局变量存储大量数据时，确保用完以后把它设置为 null 或者重新定义。与全局变量相关的增加内存消耗的一个主因是缓存。缓存数据是为了重用，缓存必须有一个大小上限才有用。高内存消耗导致缓存突破上限，因为缓存内容无法被回收。

2：被遗忘的计时器或回调函数

在 JavaScript 中使用 setInterval

Eine weitere unerwartete globale Variable kann durch dies erstellt werden: 🎜🎜🎜Fügen Sie 'use strict' zum Header Ihrer JavaScript-Datei hinzu, um diese Art von Fehler zu vermeiden. Aktivieren Sie das Parsen von JavaScript im strikten Modus, um unerwartete globale Variablen zu vermeiden. 🎜🎜🎜Hinweise 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). Insbesondere wenn globale Variablen zur temporären Speicherung und Verarbeitung großer Informationsmengen verwendet werden, ist Vorsicht geboten. 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: 🎜

Was dieses Beispiel veranschaulicht: Der mit dem Knoten oder den Daten verknüpfte Timer wird nicht mehr benötigt, das node-Objekt kann gelöscht werden und die gesamte Callback-Funktion wird nicht mehr benötigt. Die Timer-Rückruffunktion wurde jedoch immer noch nicht recycelt (sie wird erst recycelt, wenn der Timer stoppt). Gleichzeitig kann someResource nicht recycelt werden, wenn darin eine große Datenmenge gespeichert ist. node 对象可以删除，整个回调函数也不需要了。可是，计时器回调函数仍然没被回收（计时器停止才会被回收）。同时，someResource 如果存储了大量的数据，也是无法被回收的。

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

观察者代码示例：

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

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

3：脱离 DOM 的引用

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

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

4：闭包

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

代码示例：

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

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

Chrome 内存剖析工具概览

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

Bei Beobachtern ist es wichtig, diese explizit zu entfernen, sobald sie nicht mehr benötigt werden (oder das zugehörige Objekt nicht mehr erreichbar ist). Der alte IE 6 kann keine Zirkelverweise verarbeiten. Heutzutage können die meisten Browser Beobachter-Handler wiederverwenden, sobald das Beobachterobjekt nicht mehr erreichbar ist, auch ohne sie explizit zu entfernen.

Observer-Codebeispiel:

Überlegungen zu Objektbeobachtern und Zirkelverweisen

Alte IE-Versionen sind nicht in der Lage, Zirkelverweise zwischen DOM-Knoten und JavaScript-Code zu erkennen, was zu Speicherverlusten führen kann. Heutzutage verwenden moderne Browser (einschließlich IE und Microsoft Edge) fortschrittlichere Garbage-Collection-Algorithmen und können Zirkelverweise korrekt erkennen und verarbeiten. Mit anderen Worten: Beim Recycling des Knotenspeichers ist es nicht erforderlich, removeEventListener aufzurufen.

3: DOM-Referenzen trennen

Manchmal ist es nützlich, die interne Datenstruktur von DOM-Knoten zu speichern. Wenn Sie schnell mehrere Zeilen einer Tabelle aktualisieren möchten, ist es sinnvoll, jede Zeile im DOM als Wörterbuch (JSON-Schlüssel-Wert-Paar) oder Array zu speichern. Zu diesem Zeitpunkt gibt es zwei Verweise auf dasselbe DOM-Element: einen im DOM-Baum und einen im Wörterbuch. Wenn Sie sich entscheiden, diese Zeilen in Zukunft zu löschen, müssen Sie beide Referenzen löschen.

Darüber hinaus müssen auch Referenzprobleme innerhalb des DOM-Baums oder der Unterknoten berücksichtigt werden. Angenommen, Ihr JavaScript-Code speichert einen Verweis auf einen <td> in der Tabelle. Wenn Sie sich entscheiden, in Zukunft die gesamte Tabelle zu löschen, gehen Sie davon aus, dass der GC andere Knoten außer dem gespeicherten <td> wiederverwenden wird. Dies ist nicht die tatsächliche Situation: Dieser <td> ist ein untergeordneter Knoten der Tabelle, und das untergeordnete Element hat eine Referenzbeziehung zum übergeordneten Element. Da der Code einen Verweis auf <td> beibehält, bleibt die gesamte Tabelle im Speicher. Seien Sie vorsichtig, wenn Sie Verweise auf DOM-Elemente speichern.

4: Abschlüsse 🎜🎜🎜 Abschlüsse sind ein wichtiger Aspekt der JavaScript-Entwicklung: Anonyme Funktionen können auf Variablen im übergeordneten Bereich zugreifen. 🎜🎜Codebeispiel: 🎜🎜Der Codeausschnitt macht eines: Jedes Mal, wenn replaceThing aufgerufen wird, erhält theThing einen neuen Abschluss, der ein großes Array ( someMethod) enthält. Code>) neues Objekt. Gleichzeitig ist die Variable <code>unused ein Abschluss, der auf originalThing verweist (das vorherige replaceThing namens theThing). . Sind Ihre Gedanken verwirrt? Das Wichtigste ist, dass sie nach der Erstellung des Abschlussbereichs denselben übergeordneten Bereich haben und der Bereich gemeinsam genutzt wird. someMethod ist über theThing verfügbar und someMethod teilt den Abschlussbereich mit unused, obwohl unused code> wird nie verwendet und das originalThing, auf das es verweist, zwingt es dazu, im Speicher zu bleiben (wodurch verhindert wird, dass es recycelt wird). Wenn dieser Code wiederholt ausgeführt wird, werden Sie feststellen, dass die Speichernutzung weiter zunimmt und der Garbage Collector (GC) die Speichernutzung nicht reduzieren kann. Im Wesentlichen wurde eine verknüpfte Liste von Abschlüssen erstellt, und jeder Abschlussbereich enthält einen indirekten Verweis auf ein großes Array, was zu einem schwerwiegenden Speicherverlust führt. 🎜

🎜Meteors Blogbeitrag erklärt, wie man dieses Problem beheben kann. Fügen Sie originalThing = null am Ende von replaceThing hinzu. 🎜

🎜Übersicht über die Chrome-Speicherprofilierungstools🎜🎜Chrome bietet eine Reihe großartiger Tools zum Erkennen der JavaScript-Speichernutzung. Zwei wichtige Tools im Zusammenhang mit dem Speicher: timeline und profiles. 🎜🎜🎜Timeline🎜🎜🎜Timeline kann unerwünschten Speicher in Ihrem Code erkennen. In diesem Screenshot sehen wir das stetige Wachstum potenzieller geleakter Objekte. Am Ende der Datenerfassung ist die Speichernutzung deutlich höher als zu Beginn der Erfassung und auch die Gesamtzahl der Knoten ist sehr hoch. Es gibt verschiedene Anzeichen dafür, dass der Code DOM-Knotenlecks aufweist. 🎜🎜🎜Profiles🎜🎜🎜Profiles ist ein Tool, auf das Sie viel Zeit konzentrieren können. Es kann Snapshots speichern, verschiedene Snapshots der JavaScript-Code-Speichernutzung vergleichen und auch die Zeitverteilung aufzeichnen. Jedes Ergebnis enthält verschiedene Arten von Listen. Bei den Listen, die sich auf Speicherlecks beziehen, handelt es sich um Zusammenfassungslisten und Vergleichslisten. 🎜🎜🎜Zusammenfassung (Zusammenfassung) Die Liste zeigt die Zuordnung und Gesamtgröße verschiedener Objekttypen: flache Größe (die Gesamtgröße aller Objekte eines bestimmten Typs), beibehaltene Größe (flache Größe plus andere damit verbundene Objektgrößen). Es bietet auch eine Vorstellung davon, wie weit ein Objekt von seinem zugehörigen GC-Wurzel entfernt ist. 🎜🎜Vergleichen Sie die Vergleichsliste verschiedener Snapshots, um Speicherlecks zu finden. 🎜

Beispiel: Verwenden von Chrome zum Erkennen von Speicherlecks

Es gibt im Wesentlichen zwei Arten von Lecks: Lecks, die durch periodisches Speicherwachstum verursacht werden, und gelegentliche Speicherlecks. Offensichtlich sind periodische Speicherlecks schwieriger zu finden und können im Allgemeinen leicht ignoriert werden. Gelegentlich auftretende Speicherlecks können als Optimierungsproblem angesehen werden, während wiederkehrende Speicherlecks als Fehler betrachtet werden, die behoben werden müssen.

Nehmen Sie den Code im Chrome-Dokument als Beispiel:

Wenn grow ausgeführt wird, werden p Knoten erstellt und in das DOM eingefügt, und globalen Variablen wird ein riesiges Array zugewiesen. Durch die oben genannten Tools lässt sich ein stetiger Speicherzuwachs feststellen. 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 时，看看相关的 object constructor，清楚地看到 (string), HTMLpElement 和 Text

Zyklisch wachsendes Gedächtnis finden

Timeline-Tags eignen sich gut dafür. Öffnen Sie das Beispiel in Chrome, öffnen Sie Dev Tools, wechseln Sie zur Zeitleiste, überprüfen Sie den Speicher, klicken Sie auf die Aufnahmeschaltfläche und klicken Sie dann auf der Seite auf die Schaltfläche The Button. Stoppen Sie die Aufnahme nach einer Weile und sehen Sie sich die Ergebnisse an:

Zwei Anzeichen zeigen einen Speicherverlust: Knoten (grüne Linie) und JS-Heap (blaue Linie) im Bild. Die Knoten wachsen stetig und nehmen nicht ab, was ein wichtiges Zeichen ist.

Die Speichernutzung des JS-Heaps wächst ebenfalls stetig. Durch den Müllsammler nicht so leicht zu finden. Die Abbildung zeigt, dass die Speichernutzung steigt und sinkt. Tatsächlich ist die Größe des JS-Heaps nach jedem Rückgang größer als zuvor. Mit anderen Worten: Auch wenn der Garbage Collector weiterhin Speicher sammelt, kommt es dennoch in regelmäßigen Abständen zu Speicherverlusten. 🎜🎜Nachdem wir bestätigt haben, dass ein Speicherverlust vorliegt, finden wir die Grundursache. 🎜🎜Speichern Sie zwei Snapshots🎜🎜Wechseln Sie zur Registerkarte „Profile“ der Chrome Dev Tools, aktualisieren Sie die Seite, warten Sie, bis die Seitenaktualisierung abgeschlossen ist, und klicken Sie auf „Take Heap Snapshot“. um den Schnappschuss als Benchmark zu speichern. Klicken Sie dann erneut auf die Schaltfläche The Button, warten Sie einige Sekunden und speichern Sie den zweiten Schnappschuss. 🎜🎜Wählen Sie „Zusammenfassung“ im Filtermenü, wählen Sie rechts „Objekte zugeordnet zwischen Snapshot 1 und Snapshot 2“ aus oder wählen Sie „Vergleich“ im Filtermenü aus, und dann wird eine Vergleichsliste angezeigt. 🎜🎜In diesem Beispiel lässt sich der Speicherverlust leicht finden. Schauen Sie sich den Size Delta-Konstruktor von (string) an, 8 MB, 58 neue Objekte. Das neue Objekt wird zugewiesen, aber nicht freigegeben und belegt 8 MB. 🎜🎜Wenn Sie den (string)-Konstruktor erweitern, werden Sie viele einzelne Speicherzuordnungen sehen. Bei der Auswahl einer individuellen Zuordnung werden die folgenden Retainer unsere Aufmerksamkeit erregen. 🎜🎜Die von uns ausgewählte Zuordnung ist Teil eines Arrays, das mit der Variablen x des Objekts window verknüpft ist. Dies zeigt den vollständigen Pfad vom riesigen Objekt zum Stamm (window), der nicht recycelt werden kann. Wir haben das potenzielle Leck gefunden und woher es kam. 🎜🎜Unser Beispiel ist relativ einfach, nur eine kleine Anzahl von DOM-Knoten ist durchgesickert und anhand des oben genannten Schnappschusses leicht zu finden. Für größere Websites bietet Chrome auch die Funktion „Heap-Zuweisungen aufzeichnen“. 🎜🎜Heap-Zuweisungen aufzeichnen, um Speicherlecks zu finden🎜🎜Gehen Sie zurück zur Registerkarte „Profile“ der Chrome Dev Tools und klicken Sie auf „Heap-Zuweisungen aufzeichnen“. Achten Sie beim Ausführen des Tools auf den blauen Balken oben, der die Speicherzuweisung darstellt. Jede Sekunde wird eine große Speicherzuweisung vorgenommen. Es läuft einige Sekunden und stoppt dann. 🎜🎜Im Bild oben sehen Sie den Trumpf des Tools: Wählen Sie eine bestimmte Zeitleiste aus und Sie können die Speicherbelegung in diesem Zeitraum sehen. Wenn man eine Zeitleiste so nah wie möglich am Höhepunkt wählt, zeigt die folgende Liste nur drei Konstruktoren: Einer ist der am häufigsten durchgesickerte (string), der nächste ist die zugehörige DOM-Zuordnung und der letzte ist Text-Konstruktor (der im DOM-Blattknoten enthaltene Text). 🎜🎜Wählen Sie einen HTMLpElement-Konstruktor aus der Liste aus und wählen Sie dann Allocation stack aus. 🎜🎜Jetzt wissen Sie, wo die Elemente zugeordnet sind (grow -> createSomeNodes. Schauen Sie sich die Zeitleiste im Bild genau an und finden Sie HTMLpElement). Der Konstruktor wird viele Male aufgerufen, was bedeutet, dass der Speicher belegt ist und nicht von GC recycelt werden kann. Wir kennen den genauen Speicherort, an dem diese Objekte zugewiesen sind (createSomeNodes). Kehren wir zum Code selbst zurück und besprechen, wie der Speicherverlust behoben werden kann. 🎜🎜Eine weitere nützliche Funktion🎜🎜Wählen Sie im Ergebnisbereich der Heap-Zuordnungen die Option „Zuordnung“ aus. 🎜🎜Diese Ansicht präsentiert eine Liste von Funktionen im Zusammenhang mit der Speicherzuweisung, und wir sehen sofort grow und createSomeNodes. Wenn Sie grow auswählen, schauen Sie sich den entsprechenden Objektkonstruktor an und sehen Sie deutlich, dass (string), HTMLpElement und Textdurchgesickert sind. 🎜🎜In Kombination mit den oben genannten Tools können Sie Speicherlecks leicht finden. 🎜🎜【Empfohlenes Lernen: 🎜Javascript-Tutorial für Fortgeschrittene🎜】🎜

Das obige ist der detaillierte Inhalt vonWie man mit Javascript-Speicherlecks umgeht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!