© Excellent backgrounds/Shutterstock.com
Java Magazin
Werkzeuge für die dynamische Memory-Leak-Analyse

Effective Java: Tool Time

Was ein Memory Leak in Java ist und unter welchen Umständen solche Leaks auftreten, wurde in den letzten Beiträgen dieser Serie geklärt. Mit welchen Strategien und Werkzeugen man nach einem vermuteten Memory Leak suchen kann, zeigt die Fortsetzung.

Angelika Langer, Klaus Kreft


Zur Erinnerung: Es gibt unterschiedliche Arten von Mem­o­ry Leaks. Alle gehen letztlich auf eine „unwanted reference“ zurück, also eine Referenz auf ein Objekt, das von der Programmlogik her nicht mehr gebraucht wird. Wegen der Referenz wird das fragliche Objekt vom Garbage Collector als erreichbar und benutzt erkannt, und sein Speicher kann deshalb nicht freigegeben werden. Störend sind diese unerwünschten Referenzen, wenn sie größere Mengen an Speicher für eine längere Zeit am Leben erhalten. Das kann im schlimmsten Fall zu einem Out­OfMemoryError der JVM und damit zum Programm­abbruch führen. Oft ist ein solcher OutOfMem­o­ryError der Ausgangspunkt für eine Memory-Leak-Analyse. Allerdings ist es dann schon reichlich spät, und es kann nur noch eine Post-mortem-Analyse gemacht werden. Dafür steht in der Regel wenig Information zur Verfügung. Oft ist es nicht mehr als ein Heap Dump.

Man muss aber nicht notwendigerweise warten, bis eine Anwendung wegen Speichermangels abbricht, ehe man nach Memory Leaks Ausschau hält. Man kann auch schon vorher – während die Applikation noch läuft – überprüfen, ob es Memory Leaks gibt. Das ist sogar empfehlenswert, denn während des Ablaufs der Anwendung können dynamische Daten von der JVM geholt werden, die weit mehr Informationen für die Analyse liefern, als es ein Heap Dump tun kann. Wir wollen uns im Folgenden beide Arten der Analyse ansehen:

die proaktive, dynamische Analyse am „lebenden Objekt“, d. h. während die Anwendung läuft die reaktive Post-mortem-Analyse, nachdem die Anwendung bereits (wegen Speichermangels) abgebrochen ist

Dazu wollen wir das Beispiel aus unserem ersten Beitrag dieser Reihe wieder aufgreifen [1]. Dort hatten wir ein kurzes, aber fehlerhaftes Programm mit Memory Leak gezeigt. Es ging um die Implementierung eines rudimentären Servers auf Basis der mit Java 7 eingeführten AsynchronousSocketChannels. Wir hatten pro Client einen Eintrag in einer Map gemacht, den wir aber am Ende der Client-Session nicht wieder gelöscht haben. Infolgedessen wächst die Map stetig an. Dies führt bei unserem Server zunächst zu Speicherengpässen mit auffallend langen Stop-the-World-Pausen des Garbage Collectors und am Ende zum Absturz mit OutOfMemoryError. Wie findet man jetzt ein solches Memory Leak?

Abb. 1: Zyklische Memory-Leak-Analyse

Dynamische Memory-Leak-Analyse mit einem Profiler

Wir wollen es gar nicht so weit kommen lassen, dass der Server mit OutOfMemoryError abstürzt, sondern wir überlegen uns vorher, welche Da...

Java Magazin
Werkzeuge für die dynamische Memory-Leak-Analyse

Effective Java: Tool Time

Was ein Memory Leak in Java ist und unter welchen Umständen solche Leaks auftreten, wurde in den letzten Beiträgen dieser Serie geklärt. Mit welchen Strategien und Werkzeugen man nach einem vermuteten Memory Leak suchen kann, zeigt die Fortsetzung.

Angelika Langer, Klaus Kreft


Zur Erinnerung: Es gibt unterschiedliche Arten von Mem­o­ry Leaks. Alle gehen letztlich auf eine „unwanted reference“ zurück, also eine Referenz auf ein Objekt, das von der Programmlogik her nicht mehr gebraucht wird. Wegen der Referenz wird das fragliche Objekt vom Garbage Collector als erreichbar und benutzt erkannt, und sein Speicher kann deshalb nicht freigegeben werden. Störend sind diese unerwünschten Referenzen, wenn sie größere Mengen an Speicher für eine längere Zeit am Leben erhalten. Das kann im schlimmsten Fall zu einem Out­OfMemoryError der JVM und damit zum Programm­abbruch führen. Oft ist ein solcher OutOfMem­o­ryError der Ausgangspunkt für eine Memory-Leak-Analyse. Allerdings ist es dann schon reichlich spät, und es kann nur noch eine Post-mortem-Analyse gemacht werden. Dafür steht in der Regel wenig Information zur Verfügung. Oft ist es nicht mehr als ein Heap Dump.

Man muss aber nicht notwendigerweise warten, bis eine Anwendung wegen Speichermangels abbricht, ehe man nach Memory Leaks Ausschau hält. Man kann auch schon vorher – während die Applikation noch läuft – überprüfen, ob es Memory Leaks gibt. Das ist sogar empfehlenswert, denn während des Ablaufs der Anwendung können dynamische Daten von der JVM geholt werden, die weit mehr Informationen für die Analyse liefern, als es ein Heap Dump tun kann. Wir wollen uns im Folgenden beide Arten der Analyse ansehen:

die proaktive, dynamische Analyse am „lebenden Objekt“, d. h. während die Anwendung läuft die reaktive Post-mortem-Analyse, nachdem die Anwendung bereits (wegen Speichermangels) abgebrochen ist

Dazu wollen wir das Beispiel aus unserem ersten Beitrag dieser Reihe wieder aufgreifen [1]. Dort hatten wir ein kurzes, aber fehlerhaftes Programm mit Memory Leak gezeigt. Es ging um die Implementierung eines rudimentären Servers auf Basis der mit Java 7 eingeführten AsynchronousSocketChannels. Wir hatten pro Client einen Eintrag in einer Map gemacht, den wir aber am Ende der Client-Session nicht wieder gelöscht haben. Infolgedessen wächst die Map stetig an. Dies führt bei unserem Server zunächst zu Speicherengpässen mit auffallend langen Stop-the-World-Pausen des Garbage Collectors und am Ende zum Absturz mit OutOfMemoryError. Wie findet man jetzt ein solches Memory Leak?

Abb. 1: Zyklische Memory-Leak-Analyse

Dynamische Memory-Leak-Analyse mit einem Profiler

Wir wollen es gar nicht so weit kommen lassen, dass der Server mit OutOfMemoryError abstürzt, sondern wir überlegen uns vorher, welche Da...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang