Automatische Rückgewinnung nicht mehr genutzten Speichers in einer Programmlaufzeit, indem Objekte identifiziert und freigegeben werden, die von den Root‑Referenzen aus nicht mehr erreichbar oder für die Ausführung des Programms nicht mehr erforderlich sind.

Prinzip

Die meisten Garbage Collector basieren auf Erreichbarkeits‑ oder Lebendigkeitsanalysen: Objekte, die von Root‑Referenzen (Stacks, Register, globale Variablen) erreichbar sind, gelten als lebendig; nicht erreichbare Objekte sind rekultivierbar. Häufige Ordnungsprinzipien sind Tracing (Mark‑and‑Sweep, Kopieren), Referenzzählung, generationelle Hypothese sowie inkrementelle/parallel laufende Sammler zur Balance zwischen Pausenzeiten und Durchsatz.

Demonstration

Beispiele: Ein generationaler JVM‑Collector, der langlebige Objekte zwischen Young und Old Generation fördert und Stop‑the‑World‑Minor‑Collections durchführt; Pythons Referenzzählung mit einem zusätzlichen Zyklendetektor; nebenläufige Collector, die parallel zu Mutator‑Threads laufen, um Pausen zu reduzieren.

Fehlanwendung

Zu glauben, GC beseitige alle speicherbezogenen Fehler — GC kann nicht erreichbare‑aber‑nicht verwendete Objekte (Speicherlecks durch verbleibende Referenzen) wiedergewinnen, noch verwaltet er automatisch nicht‑speicherliche Ressourcen (Dateideskriptoren, Sockets), es sei denn, Finalizer oder RAII‑ähnliche Muster werden bewusst eingesetzt. Ebenfalls falsch ist, GC‑Pausen in echtzeit‑ oder latenzsensitiven Systemen als vernachlässigbar anzusehen.

Konsequenz

Richtig eingesetzt reduziert GC manuelle Speicherverwaltungsfehler (Use‑after‑free, Double‑free) und verringert die Belastung des Programmierers, wodurch sichere Abstraktionen möglich werden. Er bringt Laufzeitkosten, potenzielle Pausen und nondeterministische Reinigungszeiten mit sich, die in latenzkritischen Umgebungen gesteuert werden müssen.

Umkehrung

Manuelle Speicherverwaltung (explizite Allokation und Deallokation durch den Programmierer oder deterministische Destruktoren) bietet vorhersehbare Freigabepunkte und oft geringeren konstanten Overhead, erhöht jedoch das Risiko von Speicherbeschädigung, Lecks und Programmierfehlern.

Abgrenzung

Gilt für verwaltete Laufzeiten und Heaps, in denen das Runtime die Objektlebenszyklen kontrolliert; schließt OS‑Level Paging/Swapping, Dateisystem‑Garbage sowie die Wiedergewinnung nicht‑speicherlicher Ressourcen aus, sofern das Runtime diese nicht ausdrücklich unterstützt. Unterschiedliche GC‑Strategien liefern verschiedene Garantien (z. B. Pausenbegrenzungen, Durchsatz).

Semantische Spannung

Spannung zwischen automatischer GC und deterministischer Ressourcenverwaltung (RAII/Ownership) sowie zwischen latenzvorhersagbaren Systemen und durchsatzorientierten Designs; GC‑Entscheidungen tauschen Programmierkomfort gegen Latenz, Speicherverbrauch und CPU‑Overhead ein.

Synthese

Garbage Collection ist der Laufzeitmechanismus, der automatisch nach nicht mehr erreichbaren Objekten sucht und deren Speicher zurückgewinnt; er verbindet Tracing‑ und Referenzzählungsansätze mit generationellen und nebenläufigen Strategien, um Pausen, Durchsatz und Komplexität auszutarieren, während nicht‑speicherliche Ressourcen und erreichbare Lecks in der Verantwortung des Programms verbleiben.