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 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 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 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 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 ist die Version der alten Generation des Parallel Scavenge Collectors, die Multithreading und „Mark-Collation“-Algorithmus verwendet.
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.
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.
-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
|
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方式 | ||||||||||||||||||||||
|
Serial 串行GC | Serial Old 串行GC | |||||||||||||||||||||
| -XX:+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 |
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
