Java-Garbage Collection und Analyse von stw in jvm

Dieser Artikel führt hauptsächlich in das schnelle Verständnis der Java-Garbage Collection und von stw in JVM ein, einschließlich Java-Codepausen, Threads in JVM und anderen verwandten Inhalten. Freunde, die es benötigen, können darauf zurückgreifen.

Der Stop-The-World-Mechanismus in Java wird als STW bezeichnet. Bei der Ausführung des Garbage-Collection-Algorithmus werden alle anderen Threads der Java-Anwendung angehalten (mit Ausnahme des Garbage-Collection-Helfers). ). Ein globales Pausenphänomen in Java, globale Pause, der gesamte Java-Code stoppt, nativer Code kann ausgeführt werden, aber nicht mit der JVM interagieren; diese Phänomene werden hauptsächlich durch GC verursacht.

Stop the World (STW) während der GC ist jedermanns größter Feind. Aber viele Leute wissen vielleicht nicht, dass es neben GC auch Pausen unter der JVM gibt.

Es gibt einen speziellen Thread in der JVM – VM Threads, der speziell zum Ausführen einiger spezieller VM-Vorgänge verwendet wird, wie z. B. Versenden von GC, Thread-Dump usw. Diese Aufgaben erfordern den gesamten Heap und alles threads Der Zustand ist statisch und kann nur ausgeführt werden, wenn er konsistent ist. Daher hat die JVM das Konzept des sicheren Punkts eingeführt und eine Möglichkeit gefunden, alle Threads zu benachrichtigen, einen statischen sicheren Punkt einzugeben, wenn ein VM-Betrieb erforderlich ist.

Neben GC gibt es auch andere VM-Vorgänge, die Sicherheitspunkte auslösen:

1 🎜>
2. Klassenneudefinition (z. B. Javaagent, durch AOP-Codeimplantation generierte Instrumentierung);

3. Verschiedene Debug-Vorgänge (z. B. Thread-Dump oder Deadlock-Prüfung);

Überwachen Sie den sicheren Punkt, um zu sehen, was mit der JVM passiert ist?

Der einfachste Weg besteht darin, einen weiteren Satz zu den GC-Parametern der JVM-Startparameter hinzuzufügen:

-XX:+PrintGCApplicationStoppedTime

Alle JVM-Pausenzeiten (nicht nur GC) werden im GC-Protokoll gedruckt.

2016-08-22T00:19:49.559+0800: 219.140: Gesamtzeit, für die Anwendungsthreads gestoppt wurden: 0,0053630 Sekunden

Dies Es ist ein sehr nützlicher erforderlicher Parameter, der fast jede Pause drucken kann ...
In Versionen vor JDK1.7.40 wird jedoch der Zeitstempel nicht gedruckt, sodass Sie nur wissen können, wie lange die JVM dauert wurde angehalten, aber ich weiß nicht, wann es aufgehört hat. Zu diesem Zeitpunkt besteht eine einfache Möglichkeit darin, „-XX:+PrintGCApplicationConcurrentTime“ hinzuzufügen, um die normale Laufzeit der JVM zwischen zwei Pausen zu drucken (auch ohne Zeitstempel), aber zumindest kann es mit dem GC-Protokoll mit Zeitstempel zum Umkehren verwendet werden Hör auf. Es ist an der Zeit, dass es passiert.

2016-08-22T00:19:50.183+0800: 219.764: Anwendungszeit: 5.6240430 Sekunden

So drucken Sie die Ursache aus Unfall Was ist mit der Pause?
Fügen Sie zwei weitere Parameter hinzu

: -XX:+PrintSafepointStatistics -XX: PrintSafepointStatisticsCount=1

Zu diesem Zeitpunkt wird so etwas gedruckt in stdout Inhalt von
vmop [threads: total initial_running wait_to_block]1913.425: GenCollectForAllocation [ 55 2 0 ] [time: spin block sync cleanup vmop] page_trap_count [ 0 0 0 0 6 ] 0

Dieses Protokoll ist in zwei Abschnitte unterteilt. Der erste Abschnitt ist der Zeitstempel, die Art des VM-Vorgangs und die Thread-Übersicht
Gesamt: die Gesamtzahl der Threads im sicheren Punkt

initially_running: Die Anzahl der Threads, die zu Beginn des sicheren Punkts ausgeführt werden

wait_to_block: Die Anzahl der Threads, die auf die Unterbrechung warten müssen bevor der VM-Vorgang beginnt

Die zweite Zeile enthält die verschiedenen Phasen beim Erreichen des Sicherheitspunkts und die Zeit, die zum Ausführen des Vorgangs benötigt wird. Der wichtigste davon ist vmop

spin: Warten darauf, dass der Thread auf den

Safepoint-Aufruf antwortet. Die Zeit des

Blocks: die Zeit, die benötigt wird, um alle Threads anzuhalten

sync: gleich spin+block, also der Zeit, die vom Anfang bis zum Betreten des sicheren Punkts benötigt wird, kann verwendet werden. Bestimmen Sie die Zeit, die zum Betreten des sicheren Punkts benötigt wird

cleanup: die Zeit Es dauert, um aufzuräumen Weitere Informationen finden Sie im Implementierungsprinzip der voreingenommenen Sperre. Anwendungen mit hoher Parallelität fügen im Allgemeinen einfach „-XX:-UseBiasedLocking“ zu den Startparametern hinzu. Darüber hinaus habe ich auch festgestellt, dass es sich bei einigen Typen um keine VM-Operationen handelt. Das Dokument besagt, dass der sichere Punkt einmal pro Sekunde eingegeben wird (wenn diese Sekunde den GC bereits durchlaufen hat, ist dies nicht erforderlich), und bei einigen ist dies nicht der Fall -Dringende Vorgänge, die am sicheren Punkt ausgeführt werden müssen. Einige Profiler-Tools vom Stichprobentyp können beispielsweise mit -DGuaranteedSafepointInterval angepasst werden, aber in Wirklichkeit geschieht dies nicht jede Sekunde und die Zeit ist variabel.

Im tatsächlichen Kampf haben wir sichere Punktprotokolle verwendet und festgestellt, dass Programme regelmäßig Thread Dump usw. aufrufen. Da das Safepoint-Protokoll jedoch standardmäßig an stdout ausgegeben wird, aktivieren wir es aufgrund der Leistung und Sauberkeit des stdout-Protokolls normalerweise nicht standardmäßig. Nur bei Bedarf öffnen.

Fügen Sie die folgenden drei Parameter hinzu, um mehr darüber zu erfahren, was in der VM passiert. Leider überträgt die JVM das Sicherheitspunktprotokoll nicht an vm.log, nur weil diese drei Parameter festgelegt sind, sondern druckt es vergeblich zweimal aus.

-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log

Zusammenfassung

Das obige ist der detaillierte Inhalt vonJava-Garbage Collection und Analyse von stw in jvm. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!