Wann werden DOMs aus dem Speicher entfernt?
Ich arbeite an einer Anwendung, die viele DOMs erstellt und entfernt. Ich habe bemerkt, dass der Prozessspeicher von der Browser-Registerkarte kontinuierlich zunimmt, obwohl der Javascript-Heapspeicher konstant bleibt. In einer Testanwendung erstelle und entferne ich divs von einem übergeordneten div.
%Vor%Ich habe bestätigt, dass der Javascript-Heap nicht mit den chrome-dev-tools leckt (ich bin neu für sie, so dass ich etwas verpasst haben könnte). Der Speicher für den Prozess nimmt jedoch weiter zu. Nach allem, was ich gelesen habe, vermute ich, dass die entfernten Doms immer noch im Domhaufen sind.
Andere Beiträge sagen auch, dass der Browser schließlich den Speicher freigeben wird, der den entfernten Doms zugeteilt wird. Im obigen Beispiel habe ich mehrmals create und delete getroffen. Mein Javascript Heap ist stabil bei 4,9 MB. Mein Prozessspeicher ist bis zu 115 MB groß. Ich habe 30 Minuten gewartet und es ist überhaupt nicht untergegangen.
Fragen
- Wann werden entfernte DOM-Elemente vollständig aus dem Browser-Prozessspeicher entfernt?
- Gibt es eine Möglichkeit, die DOM-Speicherbereinigung zu erzwingen?
- Gibt es ein Tool, um mehr darüber zu erfahren, welche Doms für die Garbage Collection markiert sind? Ich konnte keinen in Chrome oder IE finden.
Danke für die Hilfe!
Bearbeiten
Ich habe die chrome dev tools benutzt und der javascript heap wächst nicht. Interessanterweise ist das einzige, was sich zwischen den Heap-Snapshots ändert, ein (Array-) Objekt. Ich verstehe, dass alles in Klammern vom Browser gesteuert wird und außerhalb meiner Reichweite liegt. Jedes nachfolgende create- & gt; delete entfernt das alte (Array-) Objekt und erstellt beim Löschen ein neues Objekt.
In der Zeitleiste kann ich sehen, dass der Javascript-Heap konstant ist und die Knoten aufgeräumt werden, aber der Speicher, wie er mit (shift + esc) gezeigt wird, geht auch dann nicht runter, wenn die Anzahl der Knoten sinkt.
Es scheint, als würde ich alles tun, um sicherzustellen, dass ich meinen Javascript-Heap aufräume, aber die Dom-Bereinigung ist außerhalb meiner Reichweite und unabhängig vom Javascript-GC. Ist diese Aussage korrekt?
Sind die entfernten Doms Teile der jungen Generation? Gibt es eine Möglichkeit, eine Begrenzung für diese Heap-Größe festzulegen? Ich wiederholte den Test, bis ich 500 MB erreicht hatte und immer noch keine Säuberung. Ich verwende Chrome 35.0.1916.114 übrigens.
2 Antworten
Ich weiß, dass Sie nach Chrome gefragt haben, aber ich werde beschreiben, wie es in Firefox funktioniert, in der Hoffnung, dass es für Sie und andere Leser von Interesse sein könnte. Chrome funktioniert möglicherweise ähnlich, da bin ich mir nicht sicher.
Mit Ihrem Testfall erhöht sich die Speicherbelegung von Firefox nicht kontinuierlich. Nur wenn Sie die Elemente zum ersten Mal erstellen / entfernen, erhöht sich die Speicherbelegung dauerhaft. Während der folgenden Erstellungs- / Entfernungszyklen wird der gesamte zugewiesene Speicher anschließend zurückgewonnen.
Zumindest in Firefox können Sie nicht erzwingen, dass dieser Speicher freigegeben wird, ohne die Seite neu zu laden. Wenn Sie wirklich viel Speicher temporär zuweisen müssen, sollten Sie dies in einem iframe tun, das Sie wegwerfen können, wenn Sie fertig sind.
Technische Details folgen:
In Firefox gibt es ein Tool, um die Speichernutzung zu überprüfen: about: memory . Es teilt den verwendeten Speicher nach Kategorie auf und verfügt über Steuerelemente, um Speicher zu erzwingen (GC / CC / Speicher minimieren).
Hier sehen Sie, wie das relevante Bit von about:memory nach dem Erstellen / Entfernen der DOM-Elemente und nach dem Einfügen von GC aussieht:
(Wenn die DOM-Knoten bereits aus dem Dokument entfernt wurden, aber noch kein Müll gesammelt wurde, werden sie unter orphan-nodes measurement angezeigt.)
Der meiste zusätzliche Speicher (angefordert bei der Erstellung der DOM-Knoten) ist für das Layout reserviert.
- Firefox erstellt, wie andere Browser auch, einen separaten Rendering-Baum (Frame-Tree in Gecko) basierend auf DOM und CSS . Dies ist ein Implementierungsdetail, auf das die Webseite nicht zugreifen kann.
- Frames in Gecko werden von Arenen .
- Die Layout-Bereiche (sogenannte PresShell-Bereiche) weisen dem Betriebssystem zusätzlichen Speicher zu, wenn keine weiteren Frames in bereits zugewiesenen Speicherplatz passen (dies geschieht, wenn Sie zum ersten Mal die 50.000 DOM-Elemente erstellen) OS bis die Seite entladen ist.
Dieses Verhalten beruht auf Messungen, die gezeigt haben, dass reale Webseiten in der Regel ungefähr benötigt werden die gleiche Anzahl von Layoutobjekten während ihrer Lebensdauer: Eine typische Webseite weist 10.000 Frames nicht nur zu, um sie zu zerstören, sondern zeigt stattdessen eine sehr einfache Seite, wie der Testfall hier.
Dieses Speichermanagement-Verhalten zahlt sich in einer verbesserten Geschwindigkeit der Frame-Zuweisung / Freigabe aus, reduziert memory fragmentation , und um böse Sicherheitslücken zu vermeiden, wenn auf einen Frame zugegriffen wird, nachdem er zerstört wurde.
Tags und Links javascript html memory-leaks dom memory-management