Welche Auswirkungen hat die Wahl des Garbage Collectors (z. B. G1GC vs. ZGC) auf die Latenzzeiten von Low-Latency-Applikationen in der JVM?

Die Wahl des Garbage Collectors (GC) bestimmt maßgeblich die Dauer und Häufigkeit der Stop-the-World (STW) Pausen, welche die Antwortzeiten (Tail Latency) von JVM-Applikationen direkt beeinflussen.

G1GC (Garbage First) unterteilt den Heap in Regionen und versucht, Pausenzeiten innerhalb eines vom Nutzer definierten Ziels zu halten. In der Praxis führen jedoch die Markierungs- und Kompaktierungsphasen bei großen Heaps oder hoher Allokationsrate zu spürbaren Latenzspitzen. Wenn der GC mit der Bereinigung nicht Schritt hält, resultiert dies in einem Full GC, der die Applikation für signifikante Zeiträume blockiert.

ZGC (Z Garbage Collector) verfolgt einen anderen Ansatz: Er führt fast alle Arbeiten, einschließlich der Kompaktierung, konkurrent zu den Applikations-Threads aus. Durch den Einsatz von Colored Pointers und Load Barriers bleiben die STW-Pausen unabhängig von der Heap-Größe meist unter einer Millisekunde.

MerkmalG1GCZGC
Pause-ZeitenMillisekunden bis Sekunden (variabel)Sub-Millisekunden (konsistent)
DurchsatzHochEtwas niedriger (CPU-Overhead)
Heap-SkalierungEffektiv bis einige GBSkaliert bis Terabytes
CPU-LastModeratHöher durch konkurrierende Threads

Die Entscheidung für einen spezifischen GC ist Teil einer fundierten IT-Consulting & Digitale Strategie, da sie Trade-offs zwischen Durchsatz und Latenz erfordert. Während G1GC durch eine effizientere CPU-Nutzung den Gesamtdurchsatz steigert, minimiert ZGC die Ausreißer in der Latenzverteilung (P99 und P99.9).

Für Applikationen, bei denen Antwortzeiten im Bereich von wenigen Millisekunden kritisch sind, ist ZGC die überlegene Wahl. G1GC ist nur dann vorzuziehen, wenn der maximale Durchsatz wichtiger ist als die Vermeidung einzelner Latenzspitzen oder wenn die verfügbaren CPU-Ressourcen stark limitiert sind.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt