Java Virtual Machine Learning – Garbage Collector-javaLernprogramm-php.cn

HotSpot JVM Collector

Oben gibt es 7 Kollektoren, die in zwei Blöcke unterteilt sind. Der obere ist der Kollektor der neuen Generation und der untere ist der Kollektor der alten Generation. Besteht eine Verbindung zwischen zwei Kollektoren, können diese gemeinsam genutzt werden.

Serial (Serial GC) Collector

Serial Collector ist ein Single-Threaded-Collector der neuen Generation Ausführung mithilfe eines Kopieralgorithmus. Während der Garbage Collection müssen alle anderen Arbeitsthreads (Benutzerthreads) angehalten werden. Es ist der Standardkollektor der neuen Generation im JVM-Client-Modus. In einer Umgebung, die auf eine einzelne CPU beschränkt ist, hat der serielle Kollektor keinen Thread-Interaktions-Overhead, sodass er natürlich die höchste Single-Thread-Sammlungseffizienz erzielen kann, indem er sich auf die Speicherbereinigung konzentriert.

ParNew (Parallel GC) Sammler

ParNew Sammler ist eigentlich eine Seriensammlung. Ein Multi -Thread-Version des Kollektors, die sich genauso verhält wie der serielle Kollektor, außer dass sie mehrere Threads für die Garbage Collection verwendet.

Parallel-Scavenge-Sammler (Parallel-Recycling-GC)

Parallel-Scavenge-Sammler auch Neu Generierungskollektor, der auch ein Kollektor ist, der einen Kopieralgorithmus und einen parallelen Multithread-Kollektor verwendet. Das Merkmal des parallelen Scavenge-Kollektors ist, dass sein Fokus sich von anderen Kollektoren unterscheidet. Der Fokus von Kollektoren wie CMS liegt darauf, die Pausenzeit des Benutzerthreads während der Speicherbereinigung so weit wie möglich zu verkürzen, während das Ziel des parallelen Scavenge-Kollektors ist besteht darin, einen realisierbaren kontrollierten Durchsatz zu erreichen. Durchsatz = Programmlaufzeit/(Programmlaufzeit + Garbage Collection-Zeit), die virtuelle Maschine lief insgesamt 100 Minuten. Unter diesen dauert die Speicherbereinigung 1 Minute und der Durchsatz beträgt 99 %.

Serial Old (Serial GC) Collector

Serial Old ist die Version des Serial Collectors der alten Generation. Es verwendet auch einen einzelnen Thread zur Durchführung der Sammlung und verwendet den „Mark-Sort“-Algorithmus. Wird hauptsächlich in virtuellen Maschinen im Client-Modus verwendet.

Parallel Old (Parallel GC) Collector

Parallel Old ist die Version der alten Generation des Parallel Scavenge Collectors, die Multithreading und „Mark-Collation“-Algorithmus verwendet.

CMS (Concurrent GC) Collector

CMS (Concurrent Mark Sweep) Collector ist eine Methode, um die kürzeste Erfassungszeit zu erreichen Die Pausenzeit ist der Zielkollektor. Der CMS-Collector wird auf Basis des „Mark-Clear“-Algorithmus implementiert. Der gesamte Collection-Prozess ist grob in 4 Schritte unterteilt:

①.Anfangsmarkierung (CMS-Anfangsmarkierung)

②.Gleichzeitige Markierung (CMS-Konkurrenzmarkierung)

③ Bemerkung (CMS-Bemerkung)

④.Gleichzeitiger Sweep (CMS-gleichzeitiger Sweep)

Die beiden Schritte des ersten Markierens und erneuten Markierens erfordern immer noch das Anhalten anderer Benutzerthreads. Die anfängliche Markierung markiert nur die Objekte, mit denen GC ROOTS direkt in Verbindung gebracht werden kann, was sehr schnell ist. Die gleichzeitige Markierungsphase ist die Phase des GC ROOTS-Root-Suchalgorithmus, die bestimmt, ob das Objekt aktiv ist. In der Neumarkierungsphase werden die Markierungsdatensätze des Teils der Objekte korrigiert, die sich aufgrund der fortgesetzten Ausführung des Benutzerprogramms während der gleichzeitigen Markierungsperiode geändert haben. Die Pausenzeit in dieser Phase ist etwas länger als in der anfänglichen Markierungsphase , aber kürzer als die gleichzeitige Markierungsphase.

Aufgrund der zeitaufwändigsten gleichzeitigen Markierungs- und gleichzeitigen Löschprozesse im gesamten Prozess kann der Collector-Thread mit dem Benutzer-Thread zusammenarbeiten, also insgesamt der Speicher des CMS-Collectors Der Recyclingprozess wird gleichzeitig mit dem Benutzerthread ausgeführt.

Vorteile des CMS-Kollektors: gleichzeitige Erfassung, geringe Pausen, aber CMS ist alles andere als perfekt. Der Kollektor weist hauptsächlich drei wesentliche Mängel auf:

Der CMS-Kollektor reagiert sehr empfindlich auf CPU-Ressourcen. In der gleichzeitigen Phase wird der Benutzerthread zwar nicht angehalten, es werden jedoch CPU-Ressourcen belegt, das Referenzprogramm wird langsamer und der Gesamtdurchsatz nimmt ab. Die Standardanzahl der von CMS gestarteten Recycling-Threads beträgt: (Anzahl der CPUs + 3) / 4.

Der CMS-Kollektor kann schwebenden Müll nicht verarbeiten, und es kann zu einem „Concurrent Mode Failure“ kommen, der nach dem Ausfall zu einem weiteren vollständigen GC führen kann. Da der Benutzerthread während der gleichzeitigen Bereinigungsphase von CMS weiterhin ausgeführt wird, wird während der Ausführung und Aufwärmung des Programms weiterhin neuer Müll generiert. Dieser Teil des Mülls erscheint nach dem Markierungsprozess nicht in dieser Sammlung und muss verarbeitet werden Warten Sie auf den nächsten GC. Bereinigen Sie es. Dieser Teil des Mülls wird „schwebender Müll“ genannt. Dies liegt auch daran, dass der Benutzer-Thread während der Garbage-Collection-Phase noch ausgeführt werden muss.
Das heißt, es muss ausreichend Speicherplatz für die Verwendung durch den Benutzer-Thread reserviert werden, sodass der CMS-Kollektor nicht warten kann, bis die alte Generation fast vollständig ist Wie bei anderen Sammlern muss vor dem Sammeln ein Teil des Speicherplatzes für den Programmbetrieb während der gleichzeitigen Sammlung reserviert werden. Unter den Standardeinstellungen wird der CMS-Kollektor aktiviert, wenn 68 % des Speicherplatzes in der alten Generation verwendet werden. Sie können auch einen Triggerprozentsatz über den Wert des Parameters -XX:CMSInitiatingOccupancyFraction angeben, um die Anzahl der Speicherrecyclingzeiten zu reduzieren und zu verbessern Leistung. Wenn der während des CMS-Betriebs reservierte Speicher die Anforderungen anderer Threads des Programms nicht erfüllen kann, tritt ein „Concurrent Mode Failure“-Fehler auf. Zu diesem Zeitpunkt startet die virtuelle Maschine einen Sicherungsplan: Aktivieren Sie vorübergehend den Serial Old Collector, um erneut zu arbeiten. Sammeln Sie Müll in der alten Generation, sodass die Pause sehr lang ist. Daher führt eine zu hohe Einstellung des Parameters -XX:CMSInitiatingOccupancyFraction leicht zu einem „Concurrent Mode Failure“-Fehler und verringert die Leistung.

Der letzte Nachteil besteht darin, dass CMS ein Sammler ist, der auf dem „Mark-Clear“-Algorithmus basiert. Nach dem Sammeln mit dem „Mark-Clear“-Algorithmus wird eine große Menge an Fragmenten generiert. Wenn zu viele Speicherplatzfragmente vorhanden sind, führt dies zu großen Problemen bei der Objektzuweisung. Beispielsweise kann der Speicherplatz bei großen Objekten keinen zusammenhängenden Speicherplatz für die Zuweisung finden und muss im Voraus eine vollständige GC auslösen. Um dieses Problem zu lösen, stellt der CMS-Kollektor einen Schalterparameter -XX:UseCMSCompactAtFullCollection bereit, der zum Hinzufügen eines Defragmentierungsprozesses nach der vollständigen GC verwendet wird. Sie können auch den Parameter -XX:CMSFullGCBeforeCompaction verwenden, um festzulegen, wie oft eine unkomprimierte vollständige Ausführung durchgeführt werden soll GC, gefolgt von einem Defragmentierungsprozess.

G1 Collector

Der G1-Kollektor (Garbage First) ist ein neuer Kollektor, der von JDK1.7 bereitgestellt wird. Der G1-Kollektor basiert auf dem „Mark-Complement“-Algorithmus, was bedeutet, dass er keine Speicherfragmentierung erzeugt. Ein weiteres Merkmal besteht darin, dass die vorherigen Collectors die gesamte neue Generation oder die alte Generation sammelten, während G1 den gesamten Java-Heap (einschließlich der neuen Generation und der alten Generation) sammelte.

Zusammenfassung der Garbage-Collector-Parameter

-XX:+

-XX:-

-XX:

-XX:

Parameter	Beschreibung
-XX:+UseSerialGC	Der Standardwert für die Ausführung von Jvm im Client-Modus. Nach dem Einschalten dieses Schalters wird die Collector-Kombination aus Serial + Serial Old für die Speicherwiederverwendung verwendet
-XX:+UseParNewGC	Nachdem Sie diesen Schalter aktiviert haben, verwenden Sie den ParNew + Serial Old Collector für die Speicherbereinigung
-XX:+UseConcMarkSweepGC	Verwenden Sie ParNew + CMS + Serial Old Collector-Kombination für Speicherrecycling, Serial Old erscheint als CMS " Gleichzeitig Der Fallback-Kollektor wird nach einem „Mode Failure“-Fehler verwendet.
-XX:+UseParallelGC	Der Standardwert für die Ausführung von Jvm im Servermodus. Verwenden Sie nach dem Einschalten dieses Schalters die Kombination Parallel Scavenge + Serial Old Collector zum Recycling
-XX:+UseParallelOldGC	Verwenden Sie Parallel Scavenge + Parallel Alte Sammlerkombination zum Recycling
-XX:SurvivorRatio	Das Kapazitätsverhältnis des Eden-Bereichs zum Survivor-Bereich in der neuen Generation, der Standardwert ist 8, was Eden:Subrvivor = 8:1 bedeutet
-XX:PretenureSizeThreshold	wird nach dem Festlegen dieses Parameters direkt auf die Größe des Objekts der alten Generation heraufgestuft , Objekte, die größer als dieser Parameter sind, werden direkt zugewiesen Zuweisung der alten Generation
-XX:MaxTenuringThreshold	Auf das Alter heraufgestuft Bei Objekten der alten Generation wird das Alter nach jedem Minor GC um 1 erhöht, und wenn es den Wert dieses Parameters überschreitet, tritt es in das alte Alter ein
-XX:UseAdaptiveSizePolicy	Passen Sie die Größe jedes Bereichs im Java-Heap und das Alter des Eintritts in die alte Generation dynamisch an
-XX :+HandlePromotionFailure	Ob das zugelassen werden soll Neue Generation zum Sammeln von Garantien. Wenn ein weiterer Überlebensraum nicht ausreicht, wird er direkt in der alten Generation beibehalten, nachdem ein kleinerer GC durchgeführt wurde
-XX:ParallelGCThreads	Set die Anzahl der Threads für parallele GC für Speicherrecycling
-XX:GCTimeRatio	Das Verhältnis der GC-Zeit zur Gesamtzeit ist 99, was bedeutet, dass 1 % der GC-Zeit zulässig ist, nur gültig bei Verwendung des Parallel Scavenge Collector
-XX:MaxGCPauseMillis	Legen Sie die maximale Pausenzeit von GC fest, gültig unter dem Parallel Scavenge Collector
-XX:CMSInitiatingOccupancyFraction	Stellen Sie den CMS-Kollektor so ein, dass er die Speicherbereinigung startet, nachdem der Speicherplatz der alten Generation verwendet wurde. Der Standardwert beträgt 68 %, nur gültig für den CMS-Kollektor, -XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSCompactAtFullCollection	Da der CMS-Collector dies tut Fragmente generieren, dieser Parameter legt fest, ob nach dem Garbage Collector ein Speicherdefragmentierungsprozess erforderlich ist. Er ist nur gültig, wenn der CMS-Collector
-XX:+CMSFullGCBeforeCompaction verwendet wird	Stellen Sie den CMS-Kollektor so ein, dass er nach mehreren Garbage Collections einen Speicherdefragmentierungsprozess durchführt. Wird normalerweise mit dem Parameter „UseCMSCompactAtFullCollection“ zur Optimierung des primitiven Typs verwendet >-XX:+DisableExplicitGC
Ob die manuelle System.gc deaktiviert werden soll	-XX:+CMSParallelRemarkEnabled
Markierungspause reduzieren	-XX: LargePageSizeInBytes	Die Größe der Speicherseite kann nicht zu groß eingestellt werden, was sich auf die Größe von Perm auswirkt, -XX:LargePageSizeInBytes=128m

Standard-GC für Client- und Servermodus

	新生代GC方式	老年代和持久代GC方式
Client	Serial 串行GC	Serial Old 串行GC
Server	Parallel Scavenge 并行回收GC	Parallel Old 并行GC

GC-Methode der neuen Generation

Alte Generation und PersistenzGenerationGC-Methode

ClientSerial Serial GC Serial Old Serial GC

ServerParallel Scavenge Parallel Scavenge Parallel Alt Parallel GC

Sun/oracle JDK GC组合方式

新生代GC方式

老年代和持久代GC方式

	新生代GC方式	老年代和持久代GC方式
-XX:+UseSerialGC	Serial 串行GC	Serial Old 串行GC
-XX:+UseParallelGC	Parallel Scavenge 并行回收GC	Serial Old 并行GC
-XX:+UseConcMarkSweepGC	ParNew 并行GC	CMS 并发GC 当出现“Concurrent Mode Failure”时采用Serial Old 串行GC
-XX:+UseParNewGC	ParNew 并行GC	Serial Old 串行GC
-XX:+UseParallelOldGC	Parallel Scavenge 并行回收GC	Parallel Old 并行GC
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	Serial 串行GC	CMS 并发GC 当出现“Concurrent Mode Failure”时采用Serial Old 串行GC