EMZETT.
Login

Garbage Collector

Garbage Collector Bild: German, Public domain, Wikimedia Commons

Kurz: Ein automatischer Mechanismus in vielen Programmiersprachen, der nicht mehr benötigten Speicher wieder freigibt.

Genauer: Erkennt Objekte, auf die im Programm nicht mehr zugegriffen werden kann, und gibt den von ihnen belegten Speicher frei, ohne dass der Programmierer das manuell tun muss (im Gegensatz zu Sprachen wie C++, wo Speicher explizit freigegeben werden muss). Läuft z. B. in Java oder JavaScript automatisch im Hintergrund, kann aber kurze Verzögerungen (“GC-Pausen”) verursachen, wenn er aktiv wird.

Im Detail

Die gängigste Erkennungsstrategie ist “Reachability”: der Garbage Collector startet bei einer Menge bekannter Wurzel-Referenzen (z. B. lokale Variablen auf dem Stack, statische Felder) und verfolgt alle davon erreichbaren Objekte. Alles, was von dort aus NICHT erreichbar ist, gilt als “Garbage” und wird freigegeben — selbst wenn zwei Objekte sich gegenseitig referenzieren, aber von außen niemand mehr auf sie zeigt, werden beide korrekt als nicht erreichbar erkannt (im Gegensatz zu einfacherem Reference Counting, das bei solchen zirkulären Referenzen versagen kann).

Moderne Garbage Collector (z. B. Javas G1 oder ZGC) arbeiten generationell: neu erzeugte Objekte landen in einem kleinen, häufig aufgeräumten Speicherbereich (“Young Generation”), da die meisten Objekte ohnehin sehr kurzlebig sind (z. B. temporäre Variablen innerhalb einer Methode). Objekte, die mehrere Aufräumdurchgänge überleben, wandern in eine “Old Generation”, die seltener, dafür aufwändiger durchsucht wird. Das minimiert die spürbaren Pausen im Normalbetrieb.

Der große Vorteil gegenüber manueller Speicherverwaltung (C, C++) ist die Vermeidung ganzer Fehlerklassen: kein Memory Leak durch vergessenes Freigeben, kein Absturz durch doppeltes Freigeben oder Zugriff auf bereits freigegebenen Speicher. Der Preis dafür ist weniger Kontrolle über den genauen Zeitpunkt der Freigabe und ein gewisser Laufzeit-Overhead.

”Stop-the-World”-Pausen

Ein bekanntes Problem klassischer Garbage Collector sind “Stop-the-World”-Pausen: Während der Aufräumdurchgang läuft, müssen alle Anwendungs-Threads kurz angehalten werden, damit sich die Referenzstruktur nicht mitten in der Analyse ändert — bei großen Heaps (viel belegtem Speicher) können diese Pausen mehrere hundert Millisekunden dauern, spürbar für zeitkritische Anwendungen wie Spiele oder Echtzeit-Handelssysteme. Moderne Collector wie ZGC oder Shenandoah reduzieren diese Pausen auf wenige Millisekunden, indem sie den Großteil der Arbeit nebenläufig zur laufenden Anwendung erledigen, statt alles anzuhalten.

Sprachen ohne Garbage Collector

Nicht jede moderne Sprache setzt auf einen klassischen Garbage Collector: Rust etwa verwaltet Speicher über ein Ownership-System, das zur Kompilierzeit prüft, wann ein Wert nicht mehr gebraucht wird, und den Speicher deterministisch ohne Laufzeit-Overhead freigibt — ein dritter Weg zwischen manueller Verwaltung (C++) und automatischem Garbage Collector (Java), der Sicherheit ohne die typischen GC-Pausen verspricht, allerdings mit einer eigenen, anspruchsvollen Lernkurve.

Siehe auch: Java, C++, Objects