Java Garbage Collection-Protokollnachrichten

Ich habe Java so konfiguriert, dass Informationen zur Speicherbereinigung in die Protokolle ausgegeben werden ( ausführliche GC ). Ich bin mir nicht sicher, was die Garbage Collection-Einträge in den Protokollen bedeuten. Ein Beispiel dieser Einträge finden Sie unten. Ich habe mich bei Google umgesehen und keine soliden Erklärungen gefunden.

Ich habe einige vernünftige Vermutungen, aber ich suche nach Antworten, die strenge Definitionen der Bedeutung der Zahlen in den Einträgen liefern, gestützt auf glaubwürdige Quellen. Eine automatische +1 für alle Antworten, die die Sun-Dokumentation zitieren. Meine Fragen sind:

1. Worauf bezieht sich PSYoungGen? Ich nehme an, es hat etwas mit der vorherigen (jüngeren?) Generation zu tun, aber was genau?
2. Was ist der Unterschied zwischen dem zweiten und dem ersten Triplett von Zahlen?
3. Warum wird ein Name (PSYoungGen) für das erste Triplett von Zahlen angegeben, nicht jedoch für das zweite?
4. Was bedeutet jede Zahl (Speichergröße) im Triplett? Beispielsweise ist in 109884K-> 14201K (139904K) der Speicher vor GC 109884k und wird dann auf 14201K reduziert. Wie ist die dritte Nummer relevant? Warum sollten wir einen zweiten Satz von Zahlen benötigen?

8109.128: [GC [PSYoungGen: 109884K-> 14201K (139904K)] 691015K-> 595332K (1119040K), 0,0454530 Sekunden]

8112.111: [GC [PSYoungGen: 126649K-> 15528K (142336K)] 707780K-> 605892K (1121472K), 0,0934560 Sekunden]

8112.802: [GC [PSYoungGen: 130344K-> 3732K (118592K)] 720708K-> 607895K (1097728K), 0,0682690 Sekunden]

Das meiste davon wird im GC-Tuning-Handbuch erklärt (das Sie sowieso gut lesen sollten).

Die Befehlszeilenoption -verbose:gcbewirkt, dass bei jeder Sammlung Informationen über die Heap- und Garbage Collection gedruckt werden. Hier wird beispielsweise von einer großen Serveranwendung ausgegeben:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Hier sehen wir zwei kleinere Sammlungen, gefolgt von einer großen Sammlung. Die Zahlen vor und nach dem Pfeil (z. B. 325407K->83000Kaus der ersten Zeile) geben die kombinierte Größe von lebenden Objekten vor bzw. nach der Speicherbereinigung an. Nach kleineren Sammlungen enthält die Größe einige Objekte, die Müll sind (nicht mehr leben), aber nicht zurückgefordert werden können. Diese Objekte sind entweder in der festen Generation enthalten oder werden von der festen oder dauerhaften Generation referenziert.

Die nächste Zahl in Klammern (z. B. (776768K)wieder aus der ersten Zeile) ist die festgeschriebene Größe des Heaps: die Menge an Speicherplatz, die für Java-Objekte verwendet werden kann, ohne dass mehr Speicher vom Betriebssystem angefordert wird. Beachten Sie, dass diese Nummer keinen der Überlebensbereiche enthält, da jeweils nur einer verwendet werden kann, und auch nicht die permanente Generierung, die die von der virtuellen Maschine verwendeten Metadaten enthält.

Das letzte Element in der Zeile (z. B. 0.2300771 secs) gibt die Zeit an, die für die Durchführung der Erfassung benötigt wird. in diesem Fall ungefähr eine Viertelsekunde.

Das Format für die Hauptsammlung in der dritten Zeile ist ähnlich.

Das Format der Ausgabe von kann -verbose:gcsich in zukünftigen Versionen ändern.

Ich bin mir nicht sicher, warum in deinem ein PSYoungGen ist. Hast du den Müllsammler gewechselt?

1. PSYoungGen bezieht sich auf den Garbage Collector, der für die Minor-Sammlung verwendet wird. PS steht für Parallel Scavenge.
2. Der erste Satz von Zahlen ist die Vorher / Nachher-Größe der jungen Generation und der zweite Satz ist für den gesamten Haufen. (Die Diagnose eines Garbage Collection-Problems beschreibt das Format.)
3. Der Name gibt die betreffende Generation und den betreffenden Kollektor an, der zweite Satz gilt für den gesamten Heap.

Ein Beispiel für eine zugehörige vollständige GC zeigt auch die Sammler, die für die alten und dauerhaften Generationen verwendet wurden:

3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] 
            [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) 
            [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]

Zum Schluss eine Zeile Ihrer Beispielprotokollausgabe aufschlüsseln:

8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]

• 107Mb vor dem GC, 14 MB nach dem GC, maximale Größe der jungen Generation 137 MB
• 675 MB Heap vor GC verwendet, 581 MB Heap nach GC verwendet, 1 GB maximale Heap-Größe
• Eine geringfügige GC trat 8109,128 Sekunden seit dem Start der JVM auf und dauerte 0,04 Sekunden

Ich wollte nur erwähnen, dass man das detaillierte GC-Protokoll mit dem bekommen kann

-XX:+PrintGCDetails 

Parameter. Dann sehen Sie die PSYoungGen- oder PSPermGen-Ausgabe wie in der Antwort.

Auch -Xloggc:gc.logscheint die gleiche Leistung zu erzeugen , wie-verbose:gc , aber Sie können eine Ausgabedatei im ersten angeben.

Anwendungsbeispiel:

java -Xloggc:./memory.log -XX:+PrintGCDetails Memory

Um die Daten besser zu visualisieren, können Sie gcviewer ausprobieren (eine neuere Version finden Sie auf github ).

Achten Sie darauf, die Parameter korrekt zu schreiben. Ich habe das "+" vergessen und mein JBoss würde ohne Fehlermeldung nicht gestartet!