JVM Müllsammler

Dies ist die einfachste GC-Implementierung, da sie grundsätzlich mit einem einzelnen Thread arbeitet. Daher friert diese GC -Implementierung alle Anwendungsthreads ein, wenn sie ausgeführt wird. Daher ist es nicht ratsam, sie in Multithread-Anwendungen wie Serverumgebungen einzusetzen.

Allerdings gab es https://www.infoq.com/presentations/JVM-Performance-Tuning-twitter-QCon-London-2012 (ein ausgezeichnetes Gespräch]von Twitter -Ingenieuren auf der QCon 2012 über die Leistung von Serial Garbage Collector - was ist eine gute Möglichkeit, diesen Sammler besser zu verstehen.

Der Serial GC ist der Garbage-Collector der Wahl für die meisten Anwendungen, die keine geringen Pausenzeiten erfordern und auf Client-Computern ausgeführt werden. Um Serial Garbage Collector zu aktivieren, können wir das folgende Argument verwenden:

**

Es ist die Standardeinstellung GC von JVM und wird manchmal als Durchlaufsammler bezeichnet. Im Gegensatz zu Serial Garbage Collector verwendet dieser mehrere Threads zur Verwaltung des Heap-Speichers . Es friert jedoch auch andere Anwendungsthreads ein, während GC ausgeführt wird.

Wenn wir diesen GC verwenden, können wir die maximale Anzahl an Garbage Collection-Threads sowie Pausenzeit, Durchsatz und Footprint__ (Heapgröße) angeben.

Die Anzahl der Garbage Collector-Threads kann mit der Befehlszeilenoption -XX gesteuert werden: ParallelGCThreads = <N> .

Das maximale Pausenzeitziel (Lücke[in Millisekunden]zwischen zwei GC ) wird mit der Befehlszeilenoption -XX angegeben: MaxGCPauseMillis = <N> .

Das maximale Durchsatzziel (gemessen an der Zeit, die für die Garbage Collection aufgewendet wurde, verglichen mit der Zeit außerhalb der Garbage Collection) wird durch die Befehlszeilenoption __-XX angegeben: GCTimeRatio = <N>.

Der maximale Heap-Footprint (die Menge an Heap-Speicher, die ein Programm während der Ausführung benötigt) wird mit der Option __-Xmx <N> angegeben.

Um Parallel Garbage Collector zu aktivieren, können wir das folgende Argument verwenden:

Die Implementierung von Concurrent Mark Sweep (CMS) verwendet mehrere Garbage Collector-Threads für die Garbage Collection. Es wurde für Anwendungen entwickelt, die kürzere Speicherbereinigungspausen bevorzugen und die es sich leisten können, Prozessorressourcen für den Speicherbereiniger zu verwenden, während die Anwendung ausgeführt wird.

Einfach ausgedrückt, reagieren Anwendungen, die diesen GC-Typ verwenden, im Durchschnitt langsamer, reagieren jedoch nicht auf die Speicherbereinigung.

Ein kurzer Punkt, der hier beachtet werden muss, ist, dass, da dieses GC gleichzeitig ist, ein Aufruf einer expliziten Speicherbereinigung wie System.gc () während der gleichzeitige Prozess ausgeführt wird, https://blogs.oracle.com/jonthecollector zur Folge hat/entry/what the heck s a[ Concurrent Mode Failure/Interrupt ].

Wenn mehr als 98% der Gesamtzeit in der CMS -Garbage Collection verbracht wird und weniger als 2% des Heapspeichers wiederhergestellt sind, wird ein OutOfMemoryError vom CMS collector geworfen. Bei Bedarf kann diese Funktion deaktiviert werden, indem Sie die Option -XX: -UseGCOverheadLimit in die Befehlszeile einfügen.

Dieser Collector verfügt auch über einen Modus, der als inkrementeller Modus bezeichnet wird. Dieser Modus wird in Java SE 8 nicht mehr unterstützt und kann in einer zukünftigen Hauptversion entfernt werden.

Um den CMS Garbage Collector zu aktivieren, können wir folgendes Flag verwenden:

G1 (Garbage First) Garbage Collector ist für Anwendungen konzipiert, die auf Multi-Prozessor-Computern mit großem Speicherplatz ausgeführt werden. Es ist seit JDK7 Update 4 und späteren Versionen verfügbar.

G1 Collector ersetzt den CMS Collector, da er leistungsstärker ist

Im Gegensatz zu anderen Kollektoren partitioniert G1 Collector den Heap in einen Satz gleichgroßer Heap-Bereiche, die jeweils einen zusammenhängenden Bereich des virtuellen Speichers bilden.

Bei der Durchführung von Speicherbereinigungen zeigt G1 eine gleichzeitige globale Markierungsphase (d. H. Phase 1, bekannt als Marking) , um die Lebendigkeit von Objekten im gesamten Heap zu bestimmen.

Nachdem die Markierungsphase abgeschlossen ist, weiß G1 , welche Regionen meistens leer sind. Es sammelt sich zuerst in diesen Bereichen, was normalerweise eine beträchtliche Menge an freiem Speicherplatz ergibt (d. H. Phase 2, bekannt als __Sweeping). Deshalb wird diese Methode der Speicherbereinigung als Garbage-First bezeichnet.

Um G1 Garbage Collector zu aktivieren, können wir das folgende Argument verwenden:

**

Java 8u20 hat einen weiteren JVM -Parameter eingeführt, um die unnötige Verwendung von Speicher zu reduzieren, indem zu viele Instanzen desselben String erstellt werden. Dies optimiert den Heapspeicher, indem doppelte String -Werte in ein globales einzelnes char[]__ ​​-Array entfernt werden.

Dieser Parameter kann durch Hinzufügen von - XX: UseStringDeduplication als JVM -Parameter aktiviert werden.