Ich habe mit dem Heap-Profiler in Chrom herumgekämpft, aber es ist sehr verwirrend. Vor allem, wenn es darin minimierte Bibliotheken gibt. Aber auch die DOMElements-Ansichten, Elemente, die nicht entfernt werden dürfen, werden sehr unübersichtlich dargestellt.
Gibt es irgendwelche Tipps, wie man den Heap-Dump in Chrome verwendet, um JS-Code zu finden, der zu Speicherlecks führt, Code, der nicht von GC bereinigt werden kann … und wie man Elemente findet, die herumspielen, selbst wenn sie aus dem Dom entfernt wurden?
Mit anderen Worten, wie liest man Heap Dump in Chrome richtig? Sicht der Dominatoren? Vergleich?
Gibt es ab 2019 neuere Inhalte?
– t3__rry
11. Februar 2019 um 16:35 Uhr
MrJingles87
Chrome bietet jetzt viel bessere Tools, um Speicherlecks zu finden, als zum Zeitpunkt der meisten Antworten.
Hier finden Sie Speicherlecks in Javascript mit einem aktuellen Chrome-Browser:
Drücken Sie F12 um die Entwicklertools zu öffnen und zu gehen Registerkarte „Speicher“..
Wählen Sie eine Funktion oder einen Teil Ihrer App aus, die Sie auf Lecks untersuchen möchten. Wenn beispielsweise ein Dialog geöffnet und wieder geschlossen wird, soll der von ihm belegte Speicher freigegeben werden.
Führen Sie die Aktion (z. B. Öffnen eines Dialogs), die Sie auf Speicherlecks prüfen möchten, einmal aus, damit potenzielle globale Dienste geladen werden können. Dadurch wird verhindert, dass diese absichtlich erhaltenen Objekte als Lecks angezeigt werden.
Wählen Sie nun aus Zeitplan für die Zuweisung von Aufzeichnungen und drücke Anfang. Wiederholen Sie die Aktion, die Sie auf Lecks prüfen möchten, einige Male. Also zum Beispiel einen Dialog öffnen, schließen und wiederholen. Während Sie dies tun, zeichnet Chrome die Zeitleiste mit teilweise grauen oder blauen Balken. Normalerweise sehen Sie einen Balken für jedes Mal, wenn Sie die Aktion auf Ihrer Seite durchgeführt haben. Wenn der Balken aus mehreren vorherigen Iterationen der Aktion teilweise blau bleibt, bedeutet dies normalerweise, dass ein Speicherleck vorliegt. Der blaue Teil des Balkens stellt Speicher dar, der zu diesem Zeitpunkt allokiert und noch nicht wieder freigegeben wurde. Stoppen Sie die Aufzeichnung, indem Sie auf den roten Punkt oben links in den Entwicklertools klicken.
Wenn Sie potenzielle Lecks sehen, müssen Sie diesen Teil der Zeitleiste untersuchen, um die Quelle zu finden. Wählen Sie einen Teil der Zeitleiste aus, der einige Iterationen Ihrer Aktionen in der Vergangenheit darstellt. Und Chrome zeigt eine Liste von Objekttypen an, die noch im Speicher vorhanden sind. Das beibehaltene Größe Spalte gibt Ihnen einen Eindruck, wie viel Speicher noch belegt ist. Navigieren Sie zu einem der Objekttypen und wählen Sie ein Objekt aus. Wenn Sie dies tun, wird die Liste der Retainer unten angezeigt.
Die Liste der Retainer zeigt die “übergeordneten” Objekte, die auf das ausgewählte Objekt verweisen. Jetzt müssen Sie sich die Retainer und Ihren Code ansehen, um zu verstehen, warum der Speicher nicht freigegeben wurde. Im Bild sehen Sie zum Beispiel das Objekt vom Typ Scope. Die zweite Zeile besagt, dass der Geltungsbereich “Kontext in initFormat()” ist. Das Problem war, dass initFormat ein Ereignis-Listener war, der nicht ungebunden war, nachdem ein Dialog verlassen wurde.
Nachdem Sie Ihren Code repariert haben, überprüfen Sie, ob das Problem behoben wurde. Aktualisieren Sie die Seite und wiederholen Sie die Schritte 3 bis 6 erneut. Wenn Sie noch nie zuvor nach Speicherlecks gesucht haben, ist es nicht unwahrscheinlich, dass Sie mehrere Probleme finden.
Zusätzliche Hinweise:
Manchmal gibt es Caches, die einen Teil des Speichers behalten. Normalerweise kann man sie ignorieren.
Wenn Sie die sehen HTMLDivElement oder andere DOM-Elemente in der Liste der Objekttypen nachsehen. Wenn die Objekte in dieser Liste rot hervorgehoben sind, bedeutet dies, dass sie nicht mehr auf Ihrer Seite vorhanden sind. Das bedeutet, dass sie irgendwo im Code referenziert werden müssen. Möglicherweise haben Sie vergessen, einen Ereignis-Listener zu entbinden.
Warum sagen Sie, dass Caches ignoriert werden können? Können sie nicht entsorgt werden?
– icanfathom
14. März 2018 um 16:29 Uhr
Ich meine, Caches werden absichtlich im Speicher gehalten, weil davon ausgegangen wird, dass sie Ihnen Leistungsvorteile bringen. Und natürlich sollte eine sinnvolle Cache-Implementierung nach einer Weile Speicher zurückgeben. Aber wenn der Cache irgendwie fehlerhaft ist oder niemals Speicher zurückgibt, schätze ich, dass es sich um ein Speicherleck handelt. Ich habe Caches geschrieben, die normalerweise ignoriert werden können, da in meinem Fall der Cache des jQuery-Elements etwas Speicher enthielt. Zuerst dachte ich, es sei ein Leck, aber ich stellte fest, dass der Speicher nach einer Weile freigegeben wurde.
– MrJingles87
15. März 2018 um 21:39 Uhr
@MrJingles87 … eine naive Frage. Wissen Sie, ob ich den Haufen JavaScript-Anwendungen oder -Skripts mit der JavaScript-Sprache speichern kann … var heap = store(...); //or store(this);
– Naiver Entwickler
12. November 2018 um 16:12 Uhr
@NaiveDeveloper: Entschuldigung, das weiß ich nicht
– MrJingles87
19. November 2018 um 16:47 Uhr
In den Chrome-Entwicklertools gibt es eine Registerkarte Zeitleiste – Speicher:
Wir können die von ihm besetzte Erinnerung beobachten.
Es gibt auch Profile – Memory, wo wir einen Schnappschuss machen und sehen können, was drin ist. Snapshots können miteinander verglichen werden:
Meistens sagt es dir nichts. Aber zumindest sieht man, welche Objekte sich anhäufen und wahrscheinlich auch die Struktur des Lecks.
Ein anderer Weg ist die Verwendung 'Task Manager'
hier ist ein Artikel dazu:
Hinweis: jsleakcheck wird nicht mehr unterstützt! Es arbeitete gegen ein inoffizielles und instabiles Dev Tools-Protokoll zum Erstellen von Heap-Snapshots. An dem Protokoll wird gearbeitet, und es ist nicht stabil genug, um jsleakcheck mit verschiedenen Chrome-Versionen am Laufen zu halten. Darüber hinaus wurde ein Kompatibilitätstool auf niedrigerer Ebene, remote_inspector_client.py, entfernt, das jsleakcheck zur Kommunikation mit Dev Tools verwendet hat.
Die Leak-Finder-for-Javascript-Seite hat jetzt einen großen Hinweis oben, der besagt, dass sie nicht mehr unterstützt wird.
Es deckt die Chrome-Entwicklertools ausführlich ab und erklärt sehr gut, wie Sie vorgehen müssen, wenn Ihre Anwendung Speicherprobleme zu haben scheint.
Wenn Sie clientseitig wiederverwendbare Scripting-Objekte entwickeln, werden Sie früher oder später feststellen, dass Sie Speicherlecks entdecken. Es besteht die Möglichkeit, dass Ihr Browser den Speicher wie ein Schwamm aufsaugt und Sie kaum einen Grund finden werden, warum die Reaktionsfähigkeit Ihrer schönen DHTML-Navigation nach dem Besuch einiger Seiten Ihrer Website stark abnimmt.
In diesem Artikel werden wir diese Muster aus einer etwas anderen Perspektive betrachten und sie mit Diagrammen und Diagrammen zur Speicherauslastung unterstützen. Wir werden auch mehrere subtilere Leckszenarien vorstellen. Bevor wir beginnen, empfehle ich Ihnen dringend, diesen Artikel zu lesen, falls Sie ihn noch nicht gelesen haben.
Warum leckt der Speicher?
Das Problem des Speicherlecks ist nicht nur auf den Internet Explorer beschränkt. Fast jeder Browser (einschließlich, aber nicht beschränkt auf Mozilla, Netscape und Opera) wird Speicher verlieren, wenn Sie angemessene Bedingungen schaffen (und es ist nicht so schwer, dies zu tun, wie wir gleich sehen werden). Aber (meiner bescheidenen Meinung nach, ymmv usw.) ist der Internet Explorer der König der Leaker.
Versteh mich nicht falsch. Ich gehöre nicht zu der Menge, die schreit: „Hey, IE hat Speicherlecks, sehen Sie sich dieses neue Tool an [link-to-tool] und überzeugen Sie sich selbst”. Lassen Sie uns diskutieren, wie beschissen Internet Explorer ist, und alle Fehler in anderen Browsern vertuschen”.
Jeder Browser hat seine eigenen Stärken und Schwächen. Zum Beispiel verbraucht Mozilla beim ersten Booten zu viel Speicher, es ist nicht gut für String- und Array-Operationen; Opera kann abstürzen, wenn Sie ein lächerlich komplexes DHTML-Skript schreiben, das seine Rendering-Engine verwirrt.
Obwohl wir uns auf Situationen mit Speicherlecks in Internet Explorer konzentrieren werden, ist diese Diskussion gleichermaßen auf andere Browser anwendbar.
Gibt es ab 2019 neuere Inhalte?
– t3__rry
11. Februar 2019 um 16:35 Uhr