© Excellent backgrounds/Shutterstock.com
Java Magazin
Garbage Collection und Memory Management

Memory Leaks

Da sich Oracle mit Java 8 noch ein wenig Zeit lässt (als anvisierter Termin wird im Moment „Sommer 2013“ genannt), wollen wir die Gelegenheit nutzen, um 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.

Angelika Langer, Klaus Kreft


Is your Garbage Collector speaking to you?

Bei der Erwähnung von Memory Leaks mag sich mancher 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 Name schon andeutet, die Ausgangsreferenzen zu allen Objekten in einer JVM. Beispiele sind die Stack Pointer zu allen Thread Stacks. Variablen von Referenztypen, die als Methodenparameter oder methodenlokale Variablen auf dem Stack angelegt werden, sind über diese Root References erreichbar und folglich markiert.

Wie passt die Garbage-Collection-Strategie mit dem Progr...

Java Magazin
Garbage Collection und Memory Management

Memory Leaks

Da sich Oracle mit Java 8 noch ein wenig Zeit lässt (als anvisierter Termin wird im Moment „Sommer 2013“ genannt), wollen wir die Gelegenheit nutzen, um 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.

Angelika Langer, Klaus Kreft


Is your Garbage Collector speaking to you?

Bei der Erwähnung von Memory Leaks mag sich mancher 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 Name schon andeutet, die Ausgangsreferenzen zu allen Objekten in einer JVM. Beispiele sind die Stack Pointer zu allen Thread Stacks. Variablen von Referenztypen, die als Methodenparameter oder methodenlokale Variablen auf dem Stack angelegt werden, sind über diese Root References erreichbar und folglich markiert.

Wie passt die Garbage-Collection-Strategie mit dem Progr...

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