Speicherverwaltung und Garbage Collector in JavaScript: Wie es funktioniert

Warum JavaScript selbst für uns aufräumt, wir aber trotzdem verstehen sollten, wie es funktioniert?

Wenn Sie in JavaScript schreiben, denken Sie selten darüber nach, was mit Variablen passiert, nachdem sie den Gültigkeitsbereich verlassen haben. Im Gegensatz zu C oder C++, wo Sie manuell free() oder delete aufrufen müssen, übernimmt JavaScript die schmutzige Arbeit der Speicherbereinigung. Das ist praktisch – bis der Moment kommt, in dem Ihre Anwendung anfängt zu „ruckeln“, Gigabytes an RAM verbraucht oder plötzlich mit einem Out of Memory-Fehler abstürzt.

Kommt Ihnen das bekannt vor? Dann lassen Sie uns verstehen, wie die Speicherverwaltung in JavaScript tatsächlich funktioniert und was der Garbage Collector in JavaScript ist. Spoiler: Es ist keine Magie, sondern ein strenger Algorithmus, den Sie beim Schreiben von Code berücksichtigen können (und sollten).

Wie JavaScript Daten speichert: Stack und Heap

Bevor wir über die Garbage Collection sprechen, müssen wir verstehen, wo die Daten leben. In JavaScript gibt es zwei Hauptspeicherbereiche:

\n
• Stack – schneller, aber begrenzter Speicher. Hier werden Primitive (Zahlen, Zeichenketten, boolesche Werte) und Referenzen auf Objekte gespeichert. Jeder Funktionsaufruf erzeugt einen neuen Frame im Stack.
\n
• Heap – ein unstrukturierter Speicherbereich, in dem Objekte, Arrays, Funktionen und Closures leben. Hier findet der Hauptkampf um den Speicher statt.
\n

Wenn Sie ein Objekt erstellen:

let user = { name: 'Ivan', age: 30 };\n

Die Referenz user landet im Stack, das Objekt selbst { name: 'Ivan', age: 30 } im Heap. Solange es mindestens eine Referenz auf das Objekt gibt, lebt es. Sobald keine Referenzen mehr vorhanden sind, wird das Objekt zu „Müll“.

Der Garbage Collector in JavaScript: Der Hauptakteur

Der Garbage Collector in JavaScript (GC) ist ein Hintergrundprozess, der regelmäßig den Heap überprüft und unerreichbare Objekte entfernt. Das klingt einfach, ist aber in der Praxis ein komplexer Kompromiss zwischen Bereinigungsgeschwindigkeit und der Leistung Ihres Codes.

Der Mark-and-Sweep-Algorithmus

Moderne Engines (V8 in Chrome, SpiderMonkey in Firefox) verwenden den Mark-and-Sweep-Algorithmus. Er arbeitet in zwei Phasen:

\n
1. Markieren: Der GC beginnt mit den Wurzelobjekten (globales Objekt, aktuelle Funktionen, lokale Variablen). Er durchläuft alle Referenzen von den Wurzeln aus und markiert jedes erreichbare Objekt.
\n
2. Sweepen (Bereinigen): Alle nicht markierten Objekte gelten als Müll und werden entfernt. Der Speicher wird freigegeben.
\n

Ein einfaches Beispiel:

let a = { data: 'A' };\nlet b = { data: 'B' };\na.ref = b;  // a verweist auf b\nb.ref = a;  // b verweist auf a\n\n// Jetzt haben wir eine zirkuläre Referenz\na = null;   // a zeigt nicht mehr auf das Objekt\nb = null;   // b zeigt nicht mehr auf das Objekt\n

Früher (vor der Einführung von Mark-and-Sweep) führten solche zirkulären Referenzen zu Speicherlecks. Aber der moderne GC versteht: Wenn beide Objekte von der Wurzel aus unerreichbar sind, sind sie Müll, selbst wenn sie aufeinander verweisen.

Objektgenerationen: Jung und Alt

Die meisten Objekte leben nicht lange. Zum Beispiel temporäre Variablen innerhalb einer Funktion. Deshalb teilt V8 den Heap in Generationen auf:

\n
• Young Generation: neue Objekte. Die Bereinigung erfolgt hier häufig und schnell (Scavenge – ein Algorithmus, der lebende Objekte in einen anderen Bereich kopiert).
\n
• Old Generation: Objekte, die mehrere Bereinigungen überlebt haben. Sie werden seltener überprüft, aber der Prozess dauert länger.
\n

Dieser Ansatz verhindert, dass die Seite während einer vollständigen Überprüfung des gesamten Heaps „einfriert“.

Speicherlecks in JavaScript: Wie man sie verursacht (und nicht sollte)

Selbst mit einem intelligenten Garbage Collector kann man Situationen schaffen, in denen Speicher nicht freigegeben wird. Hier sind die häufigsten Ursachen für Speicher