Memory Leaks Tools

Von Angelika Langer und Klaus Kreft

Was ein Memory Leak in Java ist und unter welchen Umständen solche Leaks auftreten, wurde im shortcut zum Thema Memory Leaks geklärt. Mit welchen Strategien und Werkzeugen man nach einem vermuteten Memory Leak suchen kann, zeigt dieser thematisch weiterführende shortcut. Er greift das Beispiel aus dem vorangegangenen shortcut wieder auf und befasst sich mit der proaktiven, dynamischen Analyse am "lebenden Objekt", d. h. während die Anwendung läuft. Des Weiteren wird die reaktive Post-mortem-Analyse, nachdem die Anwendung bereits (wegen Speichermangels) abgebrochen ist, veranschaulicht.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 6. Sept. 2013
• ISBN: 9783868024654

Buchvorschau

Angelika Langer, Klaus Kreft

Memory Leaks Tools

ISBN: 978-3-86802-465-4

© 2013 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Effective Java: Tool Time – Werkzeuge für die dynamische Memory-Leak-Analyse

Was ein Memory Leak in Java ist und unter welchen Umständen solche Leaks auftreten, wurde im shortcut zum Thema Memory Leaks geklärt. Mit welchen Strategien und Werkzeugen man nach einem vermuteten Memory Leak suchen kann, zeigt dieser thematisch weiterführende shortcut.

Zur Erinnerung: Es gibt unterschiedliche Arten von Memory 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 OutOfMemoryError der JVM und damit zum Programmabbruch führen. Oft ist ein solcher OutOfMemoryError 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 dem vorangegangenen shortcut 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