Lesen von Java Memory Management und GC Viewer

Dies ist ein Protokoll, als ich eine Anwendung untersuchte, die von OOM Killer aufgrund von Speichermangel in der JVM getötet wurde. Ich habe GC Viewer verwendet, um die GC-Protokolldatei auf den Übergang der Speichernutzung zu überprüfen.

Vorher habe ich auch die Gliederung der Java-Speicherverwaltung neu organisiert, also habe ich sie beschrieben.

Übersicht über die Java-Speicherverwaltung

Zum Anzeigen von GCViewer benötigen Sie einige Grundkenntnisse in der Java-Speicherverwaltung.

Dieser Artikel war sehr hilfreich. Vielen Dank. http://qiita.com/opengl-8080/items/64152ee9965441f7667b

Ein sehr grobes Diagramm, das die Speicherstruktur zeigt. Es gibt zwei große Bereiche, den Heap-Bereich und den Native-Bereich. Der Heap ist ein Bereich, der von Java-Programmen verwendet wird, und im Programm erstellte Objekte werden in diesem Heap-Bereich abgelegt. Auf der anderen Seite wird der native Bereich zum Verwalten des Speichers und der Threads verwendet, die für die Ausführung der JVM erforderlich sind.

(Quelle: http://qiita.com/opengl-8080/items/64152ee9965441f7667b#java-%E3%81%AE%E3%83%A1%E3%83%A2%E3%83%AA%E7%AE% A1% E7% 90% 86)

Anhand der obigen Informationen können Sie erkennen, dass sich auf dem Haufen Jung (Neu) und Alt (Tenurd) befinden.

Der Fluss der GC scheint wie folgt zu sein.

Neu erstellte Objekte werden im Bereich Eden des Bereichs Young gespeichert
Wenn Eden voll ist, wird der GC im Bereich "Neu" (Scavenge GC genannt, der häufig ausgeführt wird) ausgeführt, und Objekte, die hier nicht zerstört werden, werden von Eden in den Bereich "Überlebende" verschoben.
Wenn der Scavenge GC das nächste Mal ausgeführt wird, ist der Umzug von Eden zu Survivor derselbe, und die Objekte im Survivor-Bereich, die nicht zerstört wurden, werden in den anderen Survivor-Bereich verschoben.
Wiederholen Sie diesen Vorgang. Wenn die Anzahl der Übertragungen den Schwellenwert überschreitet, wird das Objekt in den alten Bereich verschoben.
Der vollständige GC wird ausgeführt, wenn der alte Bereich voll ist. Die Verarbeitung dauert jedoch lange. Daher sollte diese Anzahl reduziert werden.

Referenzseite

http://qiita.com/taisho6339/items/a6a7954bd473e16706bd http://blog.pepese.com/entry/20120508/1336467306 http://www.whitemark.co.jp/tec/java/javagc.html

Versuchen Sie auf dieser Grundlage, GC Viewer zu verwenden

https://github.com/chewiebug/GCViewer/wiki/Changelog Das Obige ist die URL zum Herunterladen der Anwendung.

Wie benutzt man

Öffnen Sie einfach die heruntergeladene Anwendung und ziehen Sie die GC-Protokolldatei per Drag & Drop. Es war einfach.

Aussicht

Zuerst werden viele Linien und Bereiche angezeigt, aber ich habe in den Ansichtseinstellungen nur die erforderlichen eingegrenzt. Der angezeigte Bereich und das Ziel sind wie folgt.

Pink ist die Altstadt
Gelb ist der junge Bereich
Die rosa Linie innerhalb des Rosas ist die Haufenverwendung des alten Bereichs.
Die graue Linie in Gelb ist die Heap-Nutzung des neuen Bereichs.
Die blaue Linie gibt die Gesamtnutzung des Heap-Bereichs an
Die schwarze Linie ist, wenn FullGC ausgeführt wird

Aus dem Obigen kann geschlossen werden, dass OOM Killer aufgrund von Speichermangel in dem Bereich ausgeführt wurde, in dem die schwarzen Linien ganz rechts dicht sind.

Bonus

Dies ist die Ausgabe von GC Viewer nach dem Erhöhen des Speichers.

Es war stabil.

das ist alles.