Java Troubleshooting

(In German) Presentation held at the Provinzial Rheinland Community Day in Düsseldorf on December 10 and 17, 2013. Apart from the slides, the presentation featured a demo of Eclipse MAT.

Transcript

1. codecentric AG Dr. Patrick Peschlow JAVA TROUBLESHOOTING
2. codecentric AG Speicherbereiche einer JVM
3. codecentric AG Speicherbereiche einer JVM – Heap − Enthält Objekte − Instanzen von Klassen − Arrays − Garbage Collection − Zwingend vorgeschrieben
4. codecentric AG Speicherbereiche einer JVM – Method Area − Enthält Objektrepräsentationen aller geladenen Klassen − Gehört logisch zum Heap − Darf aber separat verwaltet werden − Garbage Collection optional
5. codecentric AG Speicherbereiche einer JVM – Thread Areas − Jeder JVM Thread hat eine eigene Thread Area − Enthält exklusiv genutzte Daten des Threads − Stack Frames dürfen zum Heap gehören, müssen dies aber nicht
6. codecentric AG Threads JVM-Prozess Gemeinsam genutzter Heap-Speicher Anwendungs- Thread 1 Anwendungs- Thread 2 JVM- Thread 1 JVM- Thread 2 JVM- Thread 3 … … Lokaler Stack Lokaler Stack Lokaler Stack Lokaler Stack Lokaler Stack
7. codecentric AG Der Heap als Objektgraph − Die Objekte im Heap lassen sich als gerichteter Graph darstellen − Objekte sind Knoten, Referenzen sind Kanten
8. codecentric AG Erreichbarkeit von Objekten GC Root Set Reachable Unreachable
9. codecentric AG Garbage Collection − Aufgabe: − Identifiziere unerreichbare Objekte − Gib deren Speicherplatz frei − Verschiedene JVMs und GC-Algorithmen verwenden unterschiedliche Aufteilungen des Heaps und Laufzeitstrategien − Generationen oder Regionen? − Separate Method Area oder ein großer Heap? − Stop-the-world oder nebenläufig? − Sequentiell oder parallel? − etc. − Daraus resultieren wiederum verschiedene Tuning-Möglichkeiten
10. codecentric AG Troubleshooting − Memory Leaks − Analyse mit Heap-Dumps bzw. basierend auf Snapshots − Exzessive Objektallokation − Analyse idealerweise „online“, um bereits entfernte Objekte aufzuzeichnen − Thread-Deadlocks − Automatische Erkennung auf Thread-Dumps − CPU-Überlastung, „JVM reagiert nicht mehr“ − Analyse von Thread-Dumps kombiniert mit OS-Metriken
11. codecentric AG Memory Leaks – Symptomatik Verwendeter Heap Normales Muster Mögliches Memory Leak
12. codecentric AG Memory Leaks – Entstehung − Memory Leaks entstehen durch Objekte, die noch referenziert aber nicht mehr benötigt werden Nicht mehr benötigte Referenz „geleakte“ Objekte
13. codecentric AG Heap-Dump − Repräsentation des Heaps in einem Binärformat − Format variiert je nach JVM-Hersteller − Enthält eine Momentaufnahme verschiedener Komponenten − Objekte, Referenzen, GC Roots, Thread Stacks, etc. − Inhalt des Dumps ist unabhängig vom verwendetem GC-Algorithmus − Analyse − In der Regel durch GUI-Tools mit „bequemen“ Analyse-/Abfragemöglichkeiten − Je nach Analyse-Tool können ggf. nicht alle Formate gelesen werden
14. codecentric AG Analyse von Heap-Dumps – Wichtige Begriffe − Shallow size − Beinhaltet die Größe aller Felder des Objekts (primitive Datentypen und Referenzen) − Deep size − Beinhaltet die Shallow size des Objekts und die Deep size (rekursiv) aller Felder des Objekts, die Referenzen sind − Retained size − Beinhaltet die Shallow size des Objekts und die Shallow size aller Objekte, die unerreichbar werden, falls dieses Objekt unerreichbar wird − Entspricht dem Speicher, der freigegeben wird, falls dieses Objekt GC‘d wird
15. codecentric AG Analyse von Heap-Dumps – Wichtige Begriffe http://help.eclipse.org/juno/topic/org.eclipse.mat.ui.help/mimes/m2268b281.png Objektgraph Dominator Tree
16. codecentric AG Demo − Eclipse Memory Analyzer (MAT) − Kann verschiedene Heap-Dump-Formate lesen − Sehr umfangreiche Analysemöglichkeiten − Erweiterung für Dumps von IBM JVMs: − „IBM Monitoring and Diagnostic Tools for Java“ − http://www.ibm.com/developerworks/java/jdk/tools/memoryanalyzer/ − Auch enthalten im IBM Support Assistant
17. codecentric AG Classloader Extension App App WAR WAR WAR Bootstrap − Auf den ersten Blick strenge Hierarchie − Aber: Isolationsanforderungen − Leak-Gefahr − durch Referenzen „von oben nach unten“
18. codecentric AG Beispiel: Classloader-Leak durch „externe“ Referenz App/WAR Classloader TestObject TestObject.class Klassen- Daten Weitere Klassen und deren Daten Method Area Heap Höherer Classloader LibObject LibObject.class Klassen- Daten Weitere Klassen und deren Daten „oben“ „unten“ − Redeployment einer Web-Applikation, Neuladen der Klasse TestObject.class − Eine LibObject-Instanz „von oben“ Classloader referenziert eine TestObject-Instanz − LibObject.class wird nicht neu geladen, so dass die Referenz bestehen bleibt
19. codecentric AG Memory Leak Detection − Manche Application Server beinhalten „Memory Leak Detection/Prevention“ − Erkennt/behebt häufige Ursachen für Classloader Leaks, z.B. − Starten aber kein Stoppen eigener Threads in Web-Anwendungen (z.B. Timer) − Nutzung von ThreadLocals ohne Cleanup − Keine Deregistrierung von registrierten Objekten (Logger, JDBC Driver, …) − Unerwartete Leaks bei Nutzung von Standard- /Fremdbibliotheken − Weitere Programmierfehler