Kaffeepause Nr. 210. Alle Arten von Garbage Collectors in Java, die Sie kennen sollten

Quelle: Hackernoon In diesem Beitrag lernen Sie die Stärken und Schwächen jedes Garbage Collector-Typs kennen, der in der Java-Entwicklung verwendet wird. Die Frage nach Garbage Collector (GC) ist in fast jedem Interview zu hören. Deshalb habe ich beschlossen, alle notwendigen Informationen über sie nach meinem Lieblingsprinzip zu sammeln – kurz und einfach. Beginnen wir zunächst mit dem Zweck von CG und warum wir mehrere Arten von Garbage Collectors benötigen. In Sprachen wie C müssen wir Objektinformationen im Speicher speichern und viel Boilerplate-Code schreiben, um diesen Speicher freizugeben. Natürlich kommt es bei solchen Programmen häufig zu Speicherlecks. Java löst das Problem von Speicherlecks mithilfe eines Garbage Collectors. Und Sie als Entwickler sollten wissen, welcher Garbage Collector am besten zu verwenden ist. Viel hängt davon ab, wo und wie Ihr Programm ausgeführt wird. Möglicherweise läuft es auf schwacher Hardware oder mit einer großen Anzahl von Objekten, oder Ihr Programm muss sehr schnell sein. Basierend auf diesen Bedingungen sollten Sie Ihren Garbage Collector optimieren, um die gewünschte Leistung zu erzielen. Also, fangen wir an.

Wie die JVM mit Speicher umgeht

Die Java Virtual Machine (JVM) unterteilt den Speicher in zwei Bereiche: den Heap, in dem Anwendungsdaten gespeichert werden, und den Nicht-Heap, in dem Programmcode und andere Daten gespeichert werden. Wenden wir uns nun dem Heap-Bereich zu. Hier erstellt unser Programm neue Objekte. Alle Garbage Collectors basieren auf der Tatsache, dass viele Programme ephemere Objekte verwenden. Das heißt, diese Objekte wurden erstellt, erfüllten dann ihre Funktion und werden nicht mehr benötigt. Die meisten dieser Objekte. Einige Objekte leben jedoch viel länger, möglicherweise sogar für die gesamte Programmdauer. Hier entsteht die Idee, Objekte in junge und alte Generationen zu unterteilen. Und wir müssen sehr oft nach der jüngeren Generation sehen. Tatsache ist, dass Garbage Collection-Prozesse in eine geringfügige Reinigung, die nur die jüngere Generation betrifft, und eine vollständige Reinigung, die beide Generationen betreffen kann, unterteilt sind. Denken Sie daran, dass der Garbage Collector ein Programm ist. Und es erfordert Zeit und Ressourcen von Ihrem Computer, um zu funktionieren. Was sich auch auf unsere Bewerbung auswirkt. Wie wirkt es sich aus? Um beispielsweise eine Garbage Collection durchzuführen, hält die JVM unsere Anwendung an. Dies wird als Stop-The-World-Pause (STW) bezeichnet. Während dieser Zeit werden alle Anwendungsthreads angehalten. Die darin enthaltene Anwendung ist sich dessen jedoch überhaupt nicht bewusst. Für die Bewerbung vergeht die Zeit gleichmäßig. Warum ist das so schlimm? Stellen Sie sich vor, Sie schreiben eine Art Austauschantrag oder einen Antrag für einen Flugzeug-Autopiloten. Ihre Anwendung könnte für eine Sekunde in den Ruhezustand versetzt werden und die Art Ihres Problems könnte sich dramatisch ändern. Das heißt, Pause ist ein wichtiger Parameter für jeden Garbage Collector. Die nächste grundlegende Eigenschaft des Garbage Collectors ist die Gesamtzeit, die für das Sammeln von Garbage aufgewendet wird, im Verhältnis zur gesamten Ausführungszeit des Programms. Was bedeutet das und warum ist es so wichtig? Anstelle einer großen „Stop-The-World“-Phase können wir einen Algorithmus mit vielen kleinen Pausen wählen. Kleine Pausen sind wünschenswert, aber nichts ist umsonst. In diesem Fall zahlen wir, indem wir die Gesamtausführungszeit des Programms verlängern. Und das müssen wir auch berücksichtigen. Der nächste Parameter ist die Menge der Hardwareressourcen. Jeder Collector benötigt Speicher zum Speichern von Objektinformationen und einen Prozessor zum Durchführen der Bereinigung. Der letzte Parameter ist die Geschwindigkeit. Die Garbage-Collection-Effizienz bezieht sich darauf, wie schnell und effizient der Garbage Collector (GC) Speicher zurückgewinnt, der nicht mehr von einem Programm verwendet wird. Alle diese Parameter beeinflussen den Algorithmus, der bei minimalem Ressourcenverbrauch schnellstmöglich Speicher freigeben kann. Werfen wir einen Blick auf die Müllsammler, die uns zur Verfügung stehen. Für das Vorstellungsgespräch müssen Sie die ersten fünf kennen. Die anderen beiden sind viel schwieriger.

Serielle GC

Serial GC ist der Garbage Collector der Java Virtual Machine und wird seit den Anfängen von Java verwendet. Dies ist nützlich für Programme mit einem kleinen Heap und der Ausführung auf weniger leistungsstarken Computern. Dieser Garbage Collector unterteilt den Heap in Regionen, zu denen Eden und Survivor gehören. Die Eden-Region ist der Pool, aus dem der Speicher für die meisten Objekte zunächst zugewiesen wird. Survivor ist ein Pool mit Objekten, die die Müllabfuhr in der Eden-Region überstanden haben. Während sich der Heap füllt, werden Objekte zwischen den Regionen Eden und Survivor verschoben. Die JVM überwacht ständig die Bewegung von Objekten in die Survivor-Regionen und wählt einen geeigneten Schwellenwert für die Anzahl solcher Bewegungen aus, nach deren Erreichen die Objekte in die Tenured-Region verschoben werden. Wenn in der Tenured-Region nicht genügend Speicherplatz vorhanden ist, übernimmt die vollständige Speicherbereinigung die Arbeit an Objekten beider Generationen. Der Hauptvorteil dieses Garbage Collectors ist sein geringer Ressourcenbedarf, sodass ein Prozessor mit geringem Stromverbrauch ausreicht, um die Sammlung durchzuführen. Der Hauptnachteil von Serial GC sind die langen Pausen bei der Garbage Collection, insbesondere wenn es um große Datenmengen geht.

Paralleler Schwerpunkt

Ein paralleler Garbage Collector (Parallel CG) ähnelt einem sequentiellen Konstruktor. Es umfasst die parallele Verarbeitung einiger Aufgaben und die Möglichkeit, Leistungseinstellungen automatisch anzupassen. Parallel GC ist ein Java Virtual Machine Garbage Collector, der auf den Ideen von Serial GC basiert, jedoch über zusätzliche Parallelität und Intelligenz verfügt. Wenn der Computer über mehr als einen Prozessorkern verfügt, wählt die ältere Version der JVM automatisch Parallel GC aus. Der Heap ist hier in die gleichen Regionen wie in Serial GC unterteilt – Eden, Survivor 0, Survivor 1 und Old Gen (Tenured). Allerdings nehmen mehrere Threads parallel an der Garbage Collection teil und der Collector kann sich an die erforderlichen Leistungsparameter anpassen. Jeder Collector-Thread verfügt über einen Speicherbereich, der gelöscht werden muss. Parallel GC verfügt auch über Einstellungen, die darauf abzielen, die erforderliche Garbage-Collection-Effizienz zu erreichen. Der Collector verwendet Statistiken aus früheren Garbage Collections, um die Leistungseinstellungen für zukünftige Collections zu optimieren. Parallel GC bietet eine automatische Optimierung der Leistungsparameter und kürzere Build-Pausenzeiten, es gibt jedoch einen kleinen Nachteil in Form einer gewissen Speicherfragmentierung. Es ist für die meisten Anwendungen geeignet, aber für komplexere Programme ist es besser, fortgeschrittenere Garbage-Collector-Implementierungen zu wählen. Vorteile: In vielen Fällen schneller als Serial GC. Hat eine gute Geschwindigkeit. Nachteile: Verbraucht mehr Ressourcen und Pausen können ziemlich lang sein, aber wir können die maximale Pausendauer von Stop-The-World anpassen.

Gleichzeitiger Mark Sweep

Der Concurrent Mark Sweep (CMS) Garbage Collector zielt darauf ab, die maximale Pausenlänge zu reduzieren, indem einige Garbage Collection-Aufgaben gleichzeitig mit Anwendungsthreads ausgeführt werden. Dieser Garbage Collector eignet sich zur Verwaltung großer Datenmengen im Speicher. Concurrent Mark Sweep (CMS) ist eine Alternative zu Parallel GC in der Java Virtual Machine (JVM). Es ist für Anwendungen gedacht, die Zugriff auf mehrere Prozessorkerne benötigen und empfindlich auf Stop-The-World-Pausen reagieren. Das CMS führt Garbage-Collection-Schritte parallel zum Hauptprogramm durch, sodass es ohne Unterbrechung ausgeführt werden kann. Es verwendet die gleiche Speicherorganisation wie die seriellen und parallelen Kollektoren, wartet jedoch nicht darauf, dass der Tenured-Bereich gefüllt ist, bevor die Bereinigung der alten Generation ausgeführt wird. Stattdessen läuft es im Hintergrund und versucht, die Tenured-Region kompakt zu halten. Concurrent Mark Sweep beginnt mit einer anfänglichen Markierungsphase, die die Hauptthreads der Anwendung kurz stoppt und alle Objekte markiert, auf die vom Root aus zugegriffen werden kann. Anschließend werden die Hauptthreads der Anwendung fortgesetzt und das CMS beginnt mit der Suche nach allen aktiven Objekten, auf die über Links von den markierten Stammobjekten aus zugegriffen werden kann. Nachdem alle lebenden Objekte markiert wurden, löscht der Kollektor in mehreren parallelen Threads den Speicher toter Objekte. Einer der Vorteile eines CMS besteht darin, dass es sich auf die Minimierung von Ausfallzeiten konzentriert, was für viele Anwendungen von entscheidender Bedeutung ist. Allerdings sind dafür Einbußen bei den CPU-Ressourcen und der Gesamtbandbreite erforderlich. Darüber hinaus komprimiert das CMS Objekte der alten Generation nicht, was zu einer Fragmentierung führt. Lange Pausen aufgrund möglicher Ausfälle im Parallelmodus können eine unangenehme Überraschung sein (obwohl sie nicht oft vorkommen). Wenn genügend Speicher vorhanden ist, kann das CMS solche Pausen vermeiden. Vorteile: Schnell. Hat kleine Stop-The-World-Pausen. Nachteile: verbraucht mehr Speicher; wenn nicht genügend Speicher vorhanden ist, können einige Pausen lang sein. Nicht sehr gut, wenn die Anwendung viele Objekte erstellt.

Garbage First

Garbage-First (G1) gilt als Alternative zu einem CMS, insbesondere für Serveranwendungen, die auf Multiprozessorservern laufen und große Datenmengen verwalten. Der G1-Garbage Collector wandelt Speicher in mehrere gleich große Regionen um, mit Ausnahme riesiger Regionen (die durch Zusammenführen regulärer Regionen zur Aufnahme massiver Objekte erstellt werden). Regionen müssen nicht in einer Reihe organisiert sein und können ihre Generationszugehörigkeit ändern. In regelmäßigen Abständen werden kleine Bereinigungen für die jüngere Generation durchgeführt und Objekte in Survivor-Regionen verschoben oder auf die ältere Generation aktualisiert und auf Tenured übertragen. Die Reinigung wird nur in den Bereichen durchgeführt, in denen eine Überschreitung der gewünschten Zeit vermieden werden muss. Der Sammler selbst prognostiziert und wählt Regionen mit der größten Müllmenge zur Reinigung aus. Vollständige Sweeps verwenden eine Markierungsschleife, um eine Liste von Live-Objekten zu erstellen, die parallel zur Hauptanwendung ausgeführt wird. Nach dem Markierungszyklus wechselt G1 zur Ausführung gemischter Bereinigungen, bei denen Regionen der älteren Generation zu den zu bereinigenden Regionen der jüngeren Generation hinzugefügt werden. Der G1-Garbage Collector gilt als genauer als der CMS-Collector bei der Vorhersage von Pausengrößen und verteilt die Garbage Collection besser über die Zeit, um lange Anwendungsausfallzeiten zu verhindern, insbesondere bei großen Heap-Größen. Es fragmentiert auch nicht den Speicher wie der CMS-Collector. Der G1-Kollektor erfordert jedoch mehr CPU-Ressourcen, um parallel zum Hauptprogramm ausgeführt zu werden, was den Anwendungsdurchsatz verringert. Vorteile: Funktioniert besser als CMS. Hat kürzere Pausen. Nachteile: Verbraucht mehr CPU-Ressourcen. Außerdem verbraucht es mehr Speicher, wenn wir viele ziemlich große Objekte (mehr als 500 KB) haben, weil es solche Objekte in einer Region (1-32 MB) ablegt.

Epsilon GC

Epsilon GC wurde für Situationen entwickelt, in denen keine Speicherbereinigung erforderlich ist. Es führt keine Garbage Collection durch, sondern verwendet TLAB (Thread-Local Allocation Buffer), um neue Objekte zuzuweisen – kleine Speicherpuffer, die von einzelnen Threads aus dem Heap angefordert werden. Riesige Objekte, die nicht in den Puffer passen, fordern gezielt Speicherblöcke für sich an. Wenn dem Epsilon GC die Ressourcen ausgehen, wird ein OutOfMemoryError generiert und der Prozess beendet. Zu den Vorteilen von Epsilon GC gehören geringere Ressourcenanforderungen und eine schnellere Speicherzuweisung für Anwendungen, die beim Start alle benötigten Objekte erstellen oder kurzlebige Anwendungen ausführen, die nicht den gesamten zugewiesenen Speicher nutzen. Epsilon GC kann auch dabei helfen, die Ressourcenanforderungen zu analysieren, die andere Garbage Collectors zu Ihrer Anwendung hinzufügen. Vorteile: Sehr schnell. Nachteile: Löscht keine Objekte :) Die nächsten beiden Sammler sind die fortschrittlichsten ihrer Art, aber auch die komplexesten. Deshalb werden wir sie kurz betrachten.

ZGC

ZGC kann selbst bei der Verarbeitung großer Datenmengen eine Latenzzeit von unter einer Millisekunde aufrechterhalten. ZGC ist ein von Oracle für Java entwickelter Garbage Collector, der einen hohen Durchsatz und eine geringe Latenz bei der Verarbeitung großer Heaps (bis zu 16 TB) bietet. ZGC basiert auf dem Prinzip des virtuellen Speichers und verwendet verschiedene Farbmarkierungen, um den Zustand von Objekten während der Speicherbereinigung zu verfolgen. Vorteile: Selbst bei großen Heaps betragen die Pausen weniger als eine Millisekunde. Dies ist sehr nützlich für Anwendungen, die kurze Abfrageverarbeitungszeiten erfordern. Es funktioniert mit sehr großen Heaps und gutem Durchsatz. ZGC kann den Heap-Speicher während der Garbage Collection komprimieren. Nachteile: Hohe CPU-Auslastung und erhebliche Leistungsanforderungen, die die Startzeiten von Anwendungen verlangsamen können.

Shenandoah G.C.

Shenandoah GC ist ein weiterer Garbage Collector mit kurzen Pausen unabhängig von der Heap-Größe. Dieser Garbage Collector wurde von Red Hat entwickelt. Es ist darauf ausgelegt, den Zeitaufwand einer Anwendung für die Speicherbereinigung zu minimieren. Wie ZGC handelt es sich um einen parallelen Kollektor, was bedeutet, dass er ausgeführt wird, während die Anwendung ausgeführt wird, wodurch Pausen minimiert werden. Shenandoah GC verwendet „Weiterleitungszeiger“, um Objekte während der Garbage Collection zu verschieben. Es verfügt außerdem über eine Technik namens „Load Barrier Removal“, um die Leistung zu verbessern. Vorteile: Shenandoah GC kann selbst bei großen Heaps kurze Pausenzeiten erreichen, oft weniger als 10 ms. Guter Durchsatz. Nachteile: hohe Prozessorauslastung und Schwierigkeiten beim Arbeiten unter hoher Last.

Abschluss

Garbage Collectors gehören zu den schwierigsten Aufgaben beim Programmieren. In diese Richtung finden laufend neue Entwicklungen statt. Auch wenn es für Programmierer selten vorkommt, den GC zu optimieren, müssen Sie dennoch zumindest flüchtige Kenntnisse darüber haben, wie Ihr Garbage-Collection-Tool funktioniert.