VisualVM ist ein Tool, mit dem Sie die Java-Speichernutzung überprüfen können. Es wird verwendet, um zu überprüfen, ob bei kontinuierlichen Belastungstests eine Tendenz zu Speicherlecks besteht. Ich denke, es ist kein neues Tool, aber ich denke, es ist immer noch ein aktives Tool, und einige Leute wissen nicht viel darüber. Deshalb habe ich ein Beispielprogramm verwendet, das dazu neigt, Speicher zu verlieren, und es leicht verwendet (soweit ich weiß). Im).
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;
public class MemoryLeak {
private static class SampleClassA {
private final List<byte[]> list = new ArrayList<>();
private void malloc() {
list.add(new byte[1024]);
}
private void clear() {
list.clear();
}
}
private static class SampleClassB {
private final List<byte[]> list = new ArrayList<>();
private void malloc() {
list.add(new byte[1024]);
}
private void clear() {
;
}
}
public static void main(String[] args) throws Exception {
SampleClassA sampleA = new SampleClassA();
SampleClassB sampleB = new SampleClassB();
while(true) {
sampleA.malloc();
sampleB.malloc();
sampleA.clear();
sampleB.clear();
TimeUnit.MILLISECONDS.sleep(100);
}
}
}
SampleClass A und Sample Class B weisen alle 100 Millisekunden jeweils 1 KB Speicher zu und geben sie frei. Es sieht fast gleich aus, aber SampleClass B gibt keinen Speicher frei.
Lassen Sie es uns einfach mit dem obigen Beispielprogramm testen.
anfangen. In diesem Beispiel verwenden wir VisualVM in Pleiades of Eclipse (unter Windows sollten Sie es mit java / 8 / bin / jvisualvm.exe starten können).
Führen Sie dieses Mal das obige Beispielprogramm von Eclipse aus. Wenn Sie es ausführen, wird das ausgeführte Programm wie unten gezeigt in VisualVM angezeigt (es wird möglicherweise nicht angezeigt, wenn Sie VisualVM separat von Eclipse herunterladen). Klicken Sie hier, um die aktuelle CPU- und Speicherauslastung anzuzeigen (siehe unten).
Notieren Sie es später zum Vergleich mit dem Status zu Beginn des Tests. Machen Sie vorerst nach dem Ausführen von GC über die Registerkarte Überwachung einen Screenshot und zeichnen Sie die aktuelle Speichernutzung auf (blauer Teil ist die aktuelle Speichernutzung). Wenn Sie oben rechts auf der Registerkarte "Überwachung" auf die Schaltfläche "Heap-Dump" klicken, können Sie die aktuell gelesenen Klasseninformationen wie unten gezeigt abrufen.
Selbst wenn die Speichernutzung vorübergehend zuzunehmen scheint, kann die Erhöhung in der Mitte aufhören. Lassen Sie sie daher für einen bestimmten Zeitraum. In der alten Firma wurde es ungefähr eine Woche lang überwacht, mindestens 3 Tage, aber es hängt davon ab, wie lange der Überwachungszeitraum tatsächlich sein sollte.
Da es problematisch ist, wird es in ungefähr 2 Stunden abgeschlossen und mit dem Ergebnis vor dem Test verglichen. Die Speichernutzung nach dem Ausführen von GC beträgt ca. 80 MB. Vor dem Test waren es ungefähr 10 MB, sodass Sie sehen können, dass es steigt. Durch den Erwerb eines neuen Heap-Dumps können Sie ihn mit dem vorherigen Heap-Dump vergleichen. Wenn Sie wie zuvor einen Heap-Dump erhalten und oben rechts auf der Registerkarte "Klasse" die Option "Mit einem anderen Heap-Dump vergleichen" auswählen, können Sie sehen, welche Arten von Instanzen wie folgt zunehmen. In diesem Fall nimmt Byte [] zu. Hier können Sie auch herausfinden, wo auf die Instanz verwiesen wird. Doppelklicken Sie im Cluster auf Byte [], klicken Sie links in der Instanz auf das entsprechende Byte und öffnen Sie dann die Referenz unten rechts. Mindestens eine der Byte [] -Instanzen wird in SampleClass B referenziert. Sie können sehen (siehe den Typ Teil). In der Produktion wird von verschiedenen Stellen aus auf verschiedene Instanzen verwiesen. In diesem Fall können Sie jedoch auch dann, wenn Sie die Referenzen anderer Instanzen öffnen, feststellen, dass sie hauptsächlich von SampleClass B referenziert werden.
Recommended Posts