Serielle GC
Die Garbage Collection verbessert die Speichereffizienz in Java, indem sie nicht referenzierte Objekte aus dem Heap entfernt und Platz für neu erstellte Objekte schafft.
Die Java Virtual Machine verfügt über acht Arten von Garbage Collectors. Betrachten wir jeden einzelnen davon im Detail.
Serial GC ist die einfachste GC-Implementierung. Es ist für kleine Anwendungen gedacht, die in Single-Thread-Umgebungen ausgeführt werden. Alle Garbage-Collection-Ereignisse werden nacheinander im selben Thread ausgeführt. Die Komprimierung wird nach jeder Speicherbereinigung durchgeführt.
Das Ausführen des Collectors führt zu einem „World Stop“-Ereignis, bei dem die gesamte Anwendung angehalten wird. Da bei der Garbage Collection die gesamte Anwendung eingefroren wird, sollten Sie im echten Leben nicht darauf zurückgreifen, wenn Sie die Verzögerungen möglichst gering halten möchten.
Das JVM-Argument zur Verwendung des seriellen Garbage Collectors ist -XX:+UseSerialGC .
Paralleler GC
Der parallele Garbage Collector ist für Anwendungen mit mittleren bis großen Datenmengen konzipiert, die auf Multithread- oder Multiprozessor-Hardware ausgeführt werden. Dies ist die Standard-GC-Implementierung und wird auch als Durchsatzkollektor bezeichnet.
Mehrere Threads sind für die kleine Müllsammlung in der jungen Generation bestimmt. Der einzige Thread ist mit der Hauptspeicherbereinigung der älteren Generation beschäftigt.
Das Ausführen eines parallelen GC führt auch dazu, dass die Welt „stoppt“ und die Anwendung hängt. Dieses Verhalten eignet sich besser für eine Multithread-Umgebung, in der viele Aufgaben abgeschlossen werden müssen und lange Pausen akzeptabel sind, beispielsweise beim Ausführen eines Batch-Jobs.
Das JVM-Argument zur Verwendung des parallelen Garbage Collectors ist -XX:+UseParallelGC .
CMS GC
Bei uns auch als Low-Rest-Parallelpicker bekannt .
Hier sind für eine kleine Garbage Collection mehrere Threads beteiligt, dies geschieht durch den gleichen Algorithmus wie im Parallel Collector. Die Haupt-Garbage Collection ist wie der alte parallele GC multithreaded, das CMS läuft jedoch gleichzeitig mit den Anwendungsprozessen, um „Weltstopp“-Ereignisse zu minimieren.
Aus diesem Grund verbraucht der CMS-Collector mehr CPU als andere Collectors. Wenn Sie die Möglichkeit haben, mehr CPU zuzuweisen, um die Leistung zu verbessern, ist ein CMS einem einfachen Parallelkollektor vorzuziehen. Der CMS GC führt keine Komprimierung durch.
Das JVM-Argument zur Verwendung des parallelen Mark-Sweep-Garbage Collectors lautet -XX:+UseConcMarkSweepGC .
G1 (Müll zuerst) GC
G1GC wurde als Ersatz für CMS konzipiert und für Multithread-Anwendungen entwickelt, die sich durch große Heap-Größen (größer als 4 GB) auszeichnen. Es ist parallel und wettbewerbsfähig wie ein CMS, aber unter der Haube funktioniert es ganz anders als die alten Garbage Collectors.
Obwohl G1 auch auf Generationenbasis arbeitet, gibt es keine getrennten Räume für jüngere und ältere Generationen. Stattdessen besteht jede Generation aus einer Reihe von Regionen, was eine flexible Änderung der Größe der jüngeren Generation ermöglicht.
G1 teilt den Heap in eine Reihe gleich großer Regionen auf (abhängig von der Größe des Heaps) und scannt diese in mehrere Threads. Der Bereich kann während der Durchführung des Programms immer wieder sowohl alt als auch jung werden.
Nachdem die Markup-Phase abgeschlossen ist, weiß G1, welche Bereiche den meisten Müll enthalten. Wenn der Benutzer an einer Minimierung der Pausen interessiert ist, kann G1 nur wenige Bereiche auswählen. Wenn die Pausenzeit für den Benutzer nicht wichtig ist oder das Pausenzeitlimit zu hoch eingestellt ist, durchläuft G1 mehr Bereiche.
Da der G1 GC die Regionen mit dem meisten Müll identifiziert und zuerst die Müllsammlung für diese Regionen durchführt, wird dies als „Garbage First“ bezeichnet.
Neben den Gebieten Eden, Survivors und Old Memory gibt es in G1GC zwei weitere Typen.
- Humongous (Huge) – für Objekte mit großer Größe (mehr als 50 % der Heap-Größe).
- Verfügbar – Ungenutzter oder nicht zugewiesener Speicherplatz.
Das JVM-Argument zur Verwendung des G1-Garbage Collectors lautet -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah ist ein neuer GC, der als Teil von JDK 12 veröffentlicht wurde. Der Hauptvorteil von Shenandoah gegenüber G1 besteht darin, dass der größte Teil des Garbage-Collection-Zyklus gleichzeitig mit Anwendungsthreads erfolgt. G1 kann Heap-Bereiche nur evakuieren, wenn die Anwendung angehalten ist, während Shenandoah Objekte gleichzeitig mit der Anwendung verschiebt.
Shenandoah kann Live-Objekte komprimieren, Müll bereinigen und RAM freigeben, fast sobald freier Speicher gefunden wird. Da all dies gleichzeitig geschieht, ohne die Anwendung anzuhalten, ist Shenandoah CPU-intensiver.
ZGC
ZGC ist ein weiterer GC, der als Teil von JDK 11 veröffentlicht und in JDK 12 verbessert wurde.
Es ist für Anwendungen gedacht, die Geschwindigkeit und geringe Latenz (Pausen von weniger als 10 ms) erfordern und/oder einen sehr großen Heap (mehrere Terabyte) verwenden.
Die Hauptziele von ZGC sind niedrige Latenz, Skalierbarkeit und Benutzerfreundlichkeit. Zu diesem Zweck ermöglicht es, dass die Java-Anwendung trotz laufender Garbage-Collection-Vorgänge weiter ausgeführt wird. Standardmäßig gibt ZGC ungenutzten Speicher frei und gibt ihn an das Betriebssystem zurück.
Somit bietet der ZGC eine deutliche Verbesserung gegenüber anderen herkömmlichen GCs, indem er extrem niedrige Totzeiten (typischerweise innerhalb von 2 ms) bietet.
Das JVM-Argument zur Verwendung des ZGC-Garbage Collectors lautet -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .