Garbage Collection

Garbage Collection und Java Virtual Machine

Alle erzeugten Objekte werden im Heap-Speicher der JVM (Java Virtual Machine) abgelegt. Da aber dieser Speicherbereich nicht unendlich groß ist, müssen die nicht mehr benötigten Objekte wieder entfernt werden. Diese Aufgabe könnte uns als Entwickler obliegen. Doch wir haben Glück: Java kennt eine automatische Speicherbereinigung, die Garbage Collection (Übersetzt: Müllabfuhr). Alle nicht referenzierten Objekte werden aus dem Heap-Speicher entfernt.
Trotzdem kann es durch unachtsame Programmierung zu Speicherlecks (Memory Leaks) kommen. Wenn eine nicht mehr benötigte Referenz noch ein Objekt, dies kann auch eine sehr große Collection sein, referenziert, wird dieses Objekt eben nicht aus dem Speicher entfernt.

Beispiel

Anhand eines kleinen Beispiels möchte ich die Garbage Collection erläutern:

public class Person {

  private String name;

  private Person partner;

  public Person( String name ) { this.name = name; }

  public Person getPartner() { return partner;       }

  public void setPartner(Person partner) { this.partner = partner; }

  public static void main(String[] args) {

    Person [ ] personen = { new Person( "Margit"), new Person("Hans" ) };

  }

}

Anschließend wollen wir unserer Person Margit einen Partner zuweisen.

public static void main(String[] args) {

  Person [ ] personen = { new Person("Margit"), new Person("Hans") };

 

  personen[0].setPartner( personen[1] );

}

Was passiert aber, wenn wir das Array an der Stelle 0 mit null initialisieren?

public static void main(String[] args) {

  Person [ ] personen = { new Person("Margit"), new Person("Hans") };

 

  personen[0].setPartner( personen[1] );

           

  personen[0] = null;

}

Arbeitsweise

Der Garbage Collector wird ausgehend von unserer Klasse Person auf dem Stack die main-Methode untersuchen. Welche Objekte können von hier erreicht werden? Über die lokale Variable personen wird das Array erreicht. An der Stelle 1 im Array wird die Person Hans referenziert und somit werden weder das Array noch die Person Hans aus dem Heap-Speicher entfernt. Der Speicher der Person Margit ist ohne Referenzierung und wird somit freigegeben.

Wie sieht es im nächsten Fall aus?

public static void main(String[] args) {

  Person [ ] personen = { new Person("Margit"), new Person("Hans") };

  personen[0].setPartner( personen[1] );

  personen[1].setPartner( personen[0] );

}

Nun initialisieren wir die lokale Variable personen mit null.

public static void main(String[] args) {

  Person [ ] personen = { new Person("Margit"), new Person("Hans") };

  personen[0].setPartner( personen[1] );

  personen[1].setPartner( personen[0] );

            

  personen = null;

}

Jetzt sieht die Sache etwas anders aus. Der Garbage Collector beginnt in der main-Methode und findet die null-Referenz in der lokalen Variablen personen, Somit ist von hier kein Objekt erreichbar. Obwohl Margit und auch Hans jeweils referenziert sind, werden sie aus dem Heap-Speicher entfernt, da sie aus der main-Methode unerreichbar sind.

 

Im nächsten Beispiel sehen wir eine zusätzliche lokale Variable misterX. Wenn nun die lokale Variable personen mit null initialisiert wird, entfernt der Garbage Collector nur das Array, nicht aber die Personen Margit und Hans, da es noch eine Referenz misterX auf die Person Margit gibt.

In der Praxis sind dies oft nicht mehr benötigte oder vergessene Referenzen, so dass die Garbage Collection diese Objekte im Speicher belässt. Man spricht hier von Memory Leaks oder Speicherlecks. Dies könnte man hier durch Dereferenzieren der lokalen Variablen misterX leicht verhindern.

public static void main(String[] args) {

  Person [ ] personen = { new Person("Margit") , new Person("Hans") };

  personen[0].setPartner( personen[1] );

  personen[1].setPartner( personen[0] );

            

  Person misterX = personen[ 0 ].getPartner( );

            

  personen = null;

}

Bevor der Garbage Collector ein Objekt aus dem Speicher entfernt, wird immer noch die Methode finalize( ) durchlaufen. Diese ist in der Klasse Object implementiert und kann überschrieben werden. Da der Entwickler aber weder weiß wann die Garbage Collection läuft, noch ob sie überhaupt läuft, ist diese Methode mit Vorsicht zu genießen. Seit JAVA 9 ist sie deprecated gekennzeichnet, weil viele Programmierer sie fehlerhaft eingesetzt haben.

Zusammenfassung

Dies war eine kurze einfache Darstellung der Garbage Collection. Alle nicht mehr erreichbaren Objekte ausgehend von der Root-Klasse und der main werden automatisch in parallelen Threads aus dem Heap-Speicher entfernt. Der Zeitpunkt ist für uns Entwickler nicht vorhersehbar.

In unserem Seminar Java Erweiterungen II (03323) wird das Thema mit schwachen (Weak Reference) und starken Referenzen vertieft.

 

Seminar zum Thema

 

Bildnachweis: Photo by Melodi2 at Morguefile.com

Weiterlesen

Referenzen und Objekte

Objekt-orientierte Programmierung ist bekanntermaßen ein sehr verbreitetes Konzept zur Modellierung komplexer Anwendungen. Die Programmiersprache Java hat bereits seit ihrer Einführung 1995 dieses Konzept aufgenommen. Auch die Laufzeitumgebung, also die Java Virtual Machine (JVM) berücksichtigt dieses Konzept und implementiert deshalb ein Speichermodell, das auf Referenzen und Objekte ausgerichtet ist.

Stack und Heap

Der Speicher der Java Virtual Machine ist in einen Stack- und einen Heap-Bereich unterteilt.

Stack und Heap der JVM

Diese Unterteilung ist zwar etwas grob, genügt aber für die folgende Betrachtung völlig.

Jede Java-Methode bekommt ihren eigenen Stack-Bereich zugeordnet. Innerhalb des Stacks werden sämtliche lokalen Variablen abgelegt. Wie im Objekt-orientierten notwendig sind diese Variablen in Java stets Referenzen auf Objekte. Diese werden im Heap-Bereich abgelegt.

Dies sei am Beispiel der folgenden main-Methode aufgezeigt:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
}

Im Speicher der JVM ergibt sich das folgende Bild:

Die main-Methode mit den lokalen Variablen message und names

Methodenaufruf

Nun definieren wir eine zweite Methode, called, diesmal mit 2 Parametern

public static void called(String str, String[] list){

}

Die methoden called mit den beiden Parametern str und list

Diese Methode wird aus main heraus aufgerufen:

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
}

Wie erfolgt nun jedoch die Übergabe der lokalen Variablen message und names in die Parameter str und list?

Wie werden die Parameter belegt?

Dazu wird die JVM die Werte der Referenzen als Kopie übergeben, also ein “CallByValue”-Verhalten auf der Ebene der Referenzen:

Copy By Value mit Referenzen

Im Endeffekt zeigen die Referenzen auf die selben Objekte im Heap.

Zuweisung von Werten

Was passiert aber nun, wenn in der aufgerufenen Methode den Parametern neue Werte zugewiesen werden? Hier ergibt sich ein feiner aber unglaublich wichtiger Unterschied: Belegen wir den Parameter str einfach mit einem neuen Wert, z.B. mit

str = "Goodbye";

so wird die Variable im Stack einfach mit einer Referenz auf das neue Objekt im Heap überschrieben:

Zuweisung eines neuen Wertes an den Parameter str

Wichtig hier ist, dass in der aufrufenden main-Methode die Variable message davon völlig unbeeinflusst bleibt.

Was passiert aber, wenn wir die Referenz auf das Array benutzen, um beispielsweise den Wert des zweiten Elements mit Index 1 auf “Paul” zu setzen?

list[1] ="Paul";

Nun ergibt sich ein anderes Bild:

Zuweisung eines neuen Wertes an das zweite Element der Liste

Hier ist klar ersichtlich, dass diese Änderung des Array-Objekts innerhalb der Methode called auch direkt Auswirkungen auf die aufrufende main-Methode hat: Nachdem die Methode called terminiert ist referenziert auch die Variable message auf das Array, dessen zweites Element nun auf “Paul” zeigt.

Also innerhalb von main

public static void main(String[] args){
String message = "Hello";
String[] names = {"John", "Fritz"};
called(message, names);
System.out.println(names[1]); //-> Paul
}

Zusammenfassung und Ausblick

Durch die Betrachtung des Speichermodells der Java Virtual Machine wird die Arbeitsweise eines Objekt-orientierten Programms unter Verwendung von Referenzen klar und verständlich. Das komplette Beispiel liegt als fertiges Eclipse-Projekt vor und enthält zusätzlich Konsolen-Ausgaben, die den Ablauf des Programms demonstrieren. Selbstverständlich kann aber auch der Eclipse-Debugger benutzt werden, um die Ausführung nachzuvollziehen.

Allerdings sind sicherlich auch noch einige Punkte nicht fundiert behandelt worden:

  • Das vorgestellte Speichermodell ist stark vereinfacht. Wie schaut es denn tatsächlich aus?
  • Was passiert eigentlich mit dem armen Objekt “Fritz”, das nun komplett losgelöst im Heap vorhanden ist?

Diese beiden Punkte werden in einem folgenden Artikel, der den Garbage Collector der JVM als Thema hat, behandelt.


Seminar zum Thema

Weiterlesen