Katalog
concept#Observability#Zuverlässigkeit#Laufzeit

Speicher Bereinigung

Automatische Freigabe von Heap-Speicher durch die Laufzeitumgebung.

Garbage Collection (GC) bezeichnet Strategien, mit denen verwaltete Laufzeitumgebungen unzugängliche Objekte automatisch erkennen und deren Speicher freigeben.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Reif

Technischer Kontext

APM/Tracing (z.B. OpenTelemetry)Heap-Analyzer (MAT, VisualVM)Feature-Flags für Collector-Switches

Prinzipien & Ziele

Deterministische Speicherverwaltung vermeidenVorhersehbare LatenzRessourceneffizienz
Umsetzung
Domäne

Use Cases & Szenarien

Kompromisse

  • Zu kleine Heaps führen zu häufigen Collections
  • Pausen-Spitzen beeinträchtigen SLAs
  • Falsch konfigurierte Logs erzeugen Overhead
  • Heap-Größen explizit festlegen statt Default nutzen
  • GC-Logs im JSON-Format für Analyse aktivieren
  • Object-Allocation-Rate überwachen und reduzieren

I/O & Ressourcen

  • Heap-Größenvorgaben (Initial- und Maximalgröße)
  • Collector- und Tuning-Parameter je nach Laufzeit
  • Monitoring- und Profiling-Tools
  • Freigegebener Heap-Speicher
  • Stabile Latenzprofile
  • GC-Telemetrie für Kapazitätsplanung

Beschreibung

Garbage Collection (GC) bezeichnet Strategien, mit denen verwaltete Laufzeitumgebungen unzugängliche Objekte automatisch erkennen und deren Speicher freigeben. Typische Ansätze sind Tracing-Collector (Mark-Sweep, Generational, Incremental, Concurrent) oder Referenzzählung mit Zyklen-Erkennung. Ziel ist es, Speicherlecks zu verhindern, manuelle Deallokation überflüssig zu machen und Latenz- sowie Durchsatzanforderungen unterschiedlicher Workloads auszubalancieren.

✔

  • Reduziert Speicherlecks und Double-Free-Fehler
  • Entwickler müssen nicht explizit deallozieren
  • Stabile Performance trotz Objektfluktuation

✖

  • Stop-the-world-Pausen können Latenz erhöhen
  • Nicht-deterministische Freigabezeiten
  • Tuning-Aufwand je nach Workload

  • Maximale GC-Pause

    Längste Stop-the-world-Dauer pro Sammlung.

  • Durchsatz (Ops/s)

    Verarbeitete Operationen pro Sekunde unter stabiler GC-Last.

  • Heap-Nutzungsgrad

    Anteil des genutzten Heaps vor und nach Collections.

Generational GC in einem Webservice

Standard-Collector mit kurzen Pausen für API-Workloads.

Nebenläufiger Collector für speicherintensive Analytics

Sehr große Heaps mit Pausen im niedrigen Millisekundenbereich.

Durchsatzorientierter Collector in Batch-Pipelines

Maximaler Durchsatz wichtiger als Latenz.

1

Workload analysieren (Latenz vs. Durchsatz)

2

Passenden Collector wählen (z.B. generational, concurrent, reference counting)

3

GC-Flags setzen, Metriken instrumentieren, Lasttest fahren

⚠️ Technische Schulden & Engpässe

  • Veraltete Laufzeitversion ohne moderne Collector-Optionen
  • Keine automatisierte GC-Log-Auswertung
  • Fehlende Loadtests für GC-Regressionen
Lange Stop-the-world-PausenFragmentierter HeapÜbermäßige Objektallokation
  • Regionenbasierter Collector mit sehr kleinem Heap in Latenz-kritischen Diensten
  • Reiner Durchsatz-Collector für UI-Anwendungen
  • Aggressive Finalizer statt klarer Lebenszyklusregeln
  • Pausen-Spitzen durch Full-GC nach Allocation-Bursts
  • Versehentliche Promotion langer Objektketten
  • Unterschätzte Fragmentierung bei nicht-kopierenden Collectors
Verständnis von Heap- und Thread-ModellenLesen und Interpretieren von GC-LogsProfiling und Leak-Diagnose
Service-Level-AgreementsHeap-Größe und ObjektlebensdauerWorkload-Muster (interactive vs. batch)
  • • Maximale Pausenzeit laut SLA
  • • Begrenzte CPU-Kerne für GC-Threads
  • • Kompatible Laufzeitversion