Memory Leaks in Java

Von Angelika Langer und Klaus Kreft

Da sich Oracle mit Java 8 noch ein wenig Zeit lässt (als anvisierter Termin wird im Moment "Frühjahr 2014" genannt), soll mit diesem shortcut die Gelegenheit genutzt werden, zu
diskutieren, wie es zu Memory Leaks in Java kommen kann und wie man sie finden oder besser schon von vorneherein vermeiden kann. Im ersten Kapitel des shortcuts
wird erläutert, dass Memory Leaks durch im Programm "vergessene" Objekte entstehen, die der Garbage Collector aber weiterhin als erreichbar identifiziert und nicht wegräumt. Zudem soll deren mögliches Aussehen gezeigt werden. Die Kapitel 2 und 3 verhandeln weitere Memory-Leak-Situationen, allgemeine
Lösungsansätze für Leaks (z. B. Weak References), und Techniken, wie man Memory Leaks suchen kann.

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

Buchvorschau

Angelika Langer, Klaus Kreft

Memory Leaks in Java

ISBN: 978-3-86802-464-7

© 2013 entwickler.press

Ein Imprint der Software & Support Media GmbH

1 Garbage Collection und Memory Management

Da sich Oracle mit Java 8 noch ein wenig Zeit lässt (als anvisierter Termin wird im Moment „Frühjahr 2014" genannt), wollen wir die Gelegenheit nutzen, um mit diesem shortcut noch einmal an die Artikelserie über Garbage Collection aus den Jahren 2010/11 anzuschließen. Wir hatten damals die Garbage Collection in der HotSpot-JVM von Sun/Oracle sowie ihr Tuning detailliert besprochen. Bei Interesse kann man diese Artikel weiterhin auf unserer Webseite [1] oder zusammengefasst als Buch [2] finden. Wir wollen anknüpfend an dieses zurückliegende Thema diskutieren, wie es zu Memory Leaks in Java kommen kann und wie man sie finden oder besser schon von vornherein vermeiden kann.

Bei der Erwähnung von Memory Leaks mag man sich Leser fragen, was denn das sein soll – ein Memory Leak in Java. Gibt es so etwas überhaupt? Eigentlich wurde doch beim Wechsel hin zu Java und weg von C bzw. C++ (also Programmiersprachen mit explizitem Memory Management durch den Programmierer) versprochen, dass Probleme wie Memory Leaks wegen dem automatischen Memory Management mittels Garbage Collector ein für alle Mal passé seien. Es stimmt schon: Memory Leaks wie in C/C++, die auf Grund von vergessenem free() bzw. delete entstehen, gibt es in Java glücklicherweise nicht mehr. Das hat den Vorteil, dass Memory Leaks in Java deutlich seltener auftreten als in C/C++. Ganz offensichtlich treten Memory Leaks in Java so selten auf, dass es eine Herausforderung ist, eines zu erzeugen. Es soll vorgekommen sein, dass Java-Entwickler in Bewerbungsgesprächen gebeten wurden, Memory Leaks zu erzeugen [3], um ihre Fähigkeiten unter Beweis zu stellen. Der Nachteil ist, dass Memory Leaks in Java meist keine Flüchtigkeitsfehler bei der Programmierung sind, sondern häufig eher Konzept- bzw. Designfehler.

Was macht der Garbage Collector?

Der Ausgangspunkt für Memory Leaks in Java ist die automatische Garbage Collection, denn allein der Garbage Collector entscheidet, wann Objekte bzw. ihr Speicher freigegeben werden. Wie macht er das? Bei allen Sun/Oracle Garbage Collectoren (außer dem Garbage First („G1") Collector, [4]) wird dazu ein Marking angewandt. Vereinfacht beschrieben sieht das so aus, dass ausgehend von den so genannten Root References alle erreichbaren Objekte markiert werden. Danach weiß der Garbage Collector, dass die markierten Objekte erreichbar sind und geht davon aus, dass diese weiter im Programm genutzt werden. Umgekehrt weiß er auch, dass er alle nicht markierten Objekte freigegeben kann. Im Detail ist das Marking, je nach Garbage-Collector-Algorithmus, eine ziemlich komplizierte Angelegenheit, die aus mehreren Phasen bestehen kann. Wer sich dafür interessiert findet die Details unter [5], [6] und [7]. Die Root References sind, wie der