So analysieren Sie die Heapdump-Datei schnell, nachdem Java sie erhalten hat

Einführung in die Heapdump-Datei

Heap-Dump: Die Heap-Dump-Datei ist eine Binärdatei, die die Verwendung von Objekten im JVM-Heap zu einem bestimmten Zeitpunkt speichert. Die HeapDump-Datei ist eine Momentaufnahme des Java-Stacks zu einem bestimmten Zeitpunkt und eine Art Bilddatei.

Heap-Dump-Fehler (Speicherüberlauf) werden im Allgemeinen aus folgenden Gründen verursacht:

1) Der JVM-Speicher ist zu klein,

2) Das Programm ist nicht streng,

3) Es wird zu viel Müll erzeugt und kann nicht sein recycelt.

Einführung

Nachdem ich das vorherige OOM-Problem überprüft habe, ist das Problem dieses Mal nicht schwerwiegend. Es löst jedoch zum Glück keinen OOM-Alarm aus In der Überprüfung wurde das Dump-Skript zusammengefasst, das bei hoher Heap-Nutzung automatisch jstack und jmap ausführt, sodass wir die problematische Site erfolgreich beibehalten können.

Überprüfen Sie die Heap-Nutzungsverteilung

Nachdem ich die Heapdump-Datei entdeckt hatte, kopierte ich sie sofort auf den lokalen Computer und analysierte sie mit MAT wie folgt:

Offensichtlich scheint es, dass eine Schnittstelle einen sehr großen String zugewiesen hat Objekt, ein String Das Objekt ist etwa 200 MB groß. Wo ist es also zugeordnet?

Finden Sie den Zuweisungsthread für große Objekte

Dieses Zuweisungsverhalten muss von einem bestimmten Thread ausgeführt werden, und der Thread ist der häufigste GC-Root. Sie müssen also nur den GC-Root des Objekts wie folgt finden:

Das große Objekt wurde gefunden. Der entsprechende Zuordnungsthread ist http-nio-8088-exec-6 wie folgt:

Thread-Stapel anzeigen

Wie überprüfe ich, was dieser Thread tut? Nachdem ich eine Weile in MAT herumgesucht hatte, fiel mir ein, dass jstack in unserem Dump-Skript aufgezeichnet war führt eine JSON-Serialisierung durch, aber ich habe sorgfältig nachgesehen. Nach einer Weile wurde der Controller der relevanten Schnittstelle nicht gefunden. Dies liegt daran, dass der Thread die Ausführung der Logik im Controller abgeschlossen hat und dann das große Objekt zurückgegeben hat, das zugewiesen wurde, als die Schnittstelle antwortete die Daten.

Da es jedoch keinen Geschäftscode im Thread-Stack gibt, ist es unmöglich herauszufinden, bei welcher Schnittstelle das Problem auftritt. . .

Überprüfen Sie das Zugriffsprotokoll.

Da die Schnittstelle zum Zuweisen großer Objekte definitiv sehr langsam sein wird, habe ich das Zugriffsprotokoll von Tomcat wie folgt überprüft:

Schließlich habe ich die problematische Schnittstelle gefunden Wird zum Abfragen von Produktdaten verwendet. Ja, wenn Sie 3 eingeben, werden alle Produkte abgefragt, die mit 3 beginnen, und es sind mehr als 200.000 Daten vorhanden. Die Lösung des Problems ist sehr einfach. Fügen Sie einfach ein Limit hinzu und fertig.

Überprüfung des Fehlerbehebungsprozesses

Allerdings hatte ich schon immer die Angewohnheit, dass ich nach der Lösung eines Problems darüber nachdenke, wie viel Glück bei der Problemlösung dabei war.

Wenn Sie häufig technische Artikel zur Fehlerbehebung lesen, werden Sie viele Artikel finden, in denen die Ursache des Problems plötzlich lokalisiert wird. Dies kann daran liegen, dass Sie plötzlich einen Hinweis entdeckt haben, oder Sie können ihn anhand des Codes erkennen Sie können es erraten. Ich denke, dieser Fehlerbehebungsprozess erfordert viel Glück. Ich hoffe, dass das Problem durch jahrelange Ansammlung theoretischer Grundlagen und den kompetenten Einsatz von Diagnosetools gefunden werden kann.

Das obige Problem kann über das Zugriffsprotokoll lokalisiert werden, was ein gewisses Maß an Glück bringt, da das Speicherproblem dieses Mal nicht extrem ist. Wenn das Anforderungsvolumen dieser Schnittstelle groß ist, werden mehrere FGCs sofort ausgelöst, was zu einer Verlangsamung führt Andere Schnittstellen herunterfahren Es gibt keine Möglichkeit herauszufinden, welche Schnittstelle das Problem verursacht!

Ich denke, theoretisch sollte es einen Thread-Stack und Parameter auf dem Thread-Stack in der Java-Heap-Datei geben. Da Threads Objekte und Parameter auch Objekte sind, sollten sie sich alle im Heap befinden, also habe ich eine freie Zeit gefunden , ich erforsche das Tool MAT erneut.

MAT Thread-Stapel anzeigen

Nachdem ich eine Weile herumgesucht hatte, fand ich eine Schaltfläche zum Anzeigen von Thread-Informationen wie folgt:

Suchen Sie den zuvor erwähnten Thread http-nio-8088-exec-6 und erweitern Sie ihn. Sie können den Thread-Stack und die Parameter auf dem Stack wie folgt finden:

Dadurch wird das Request-Parameterobjekt der Anfrage gefunden. Nachdem Sie das Request-Objekt mehrmals erweitert haben, können Sie die Schnittstellen-URL-Informationen wie folgt finden :

VisualVM View Thread Stack

Angesichts der Tatsache, dass viele Schüler es gewohnt sind, VisualVM zum Analysieren von Heapdumps zu verwenden, erfahren Sie hier, wie Sie VisualVM verwenden.

Laden Sie zunächst die Heapdump-Datei wie folgt:

Wählen Sie dann das entsprechende Objekt aus, klicken Sie mit der rechten Maustaste und wählen Sie „In Threads auswählen“ wie folgt aus:

Nachdem Sie den Thread-Stapel gefunden haben, suchen Sie das Anforderungsobjekt, das Sie anzeigen möchten, und klicken Sie zur Eingabe wie folgt:

Erweitern Sie auf ähnliche Weise das Request-Objekt. Danach finden Sie die URL-Informationen wie folgt:

Das obige ist der detaillierte Inhalt vonSo analysieren Sie die Heapdump-Datei schnell, nachdem Java sie erhalten hat. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!