6.5 Objekte anlegen und zerstören 

Wenn Objekte mit dem new-Operator angelegt werden, reserviert die Speicherverwaltung des Laufzeitsystems auf dem System-Heap Speicher. Wird das Objekt nicht mehr referenziert, so räumt der Garbage-Collector (GC) in bestimmten Abständen auf und gibt den Speicher an das Laufzeitsystem zurück.

6.5.1 Konstruktoren schreiben 

Ein Konstruktor wird automatisch aufgerufen, wenn ein Objekt mit dem new-Operator angelegt wird. Mit einem eigenen Konstruktor lässt sich erreichen, dass ein Objekt nach seiner Erzeugung einen sinnvollen Anfangszustand aufweist. Dies kann bei Klassen, die Variablen beinhalten, notwendig sein, da sie ohne vorherige Zuweisung beziehungsweise Initialisierung keinen Sinn machen würden.

Die Konstruktoren tragen denselben Namen wie die Klasse und sehen wie eine Methode ohne Rückgabewert aus. Da mitunter mehrere Konstruktoren mit unterschiedlichen Parameterlisten vorkommen, ist der Konstruktor oft überladen.

class Socke
{
  Socke()
  {
    farbe = "schwarz";
    groesse = 40;
  }
  Socke( String farbe  )
  {
    this.farbe = farbe;
    groesse = 40;
  }
  Socke( String farbe, int groesse )
  {
    this.farbe = farbe;
    this.groesse = groesse;
  }
  private String farbe;
  private int    groesse;
}

Damit ergibt sich folgendes UML-Diagramm:

Hier klicken, um das Bild zu Vergrößern

Der Standard-Konstruktor

Wenn wir in unseren Klassen keinen Konstruktor angeben, so legt der Compiler automatisch einen Standard-Konstruktor an. Wenn es jedoch mindestens einen ausprogrammierten Konstruktor gibt, wird dieser Standard-Konstruktor nicht mehr automatisch angelegt. Wollen wir daher ein Objekt einfach mit dem Standard-Konstruktor new Klassenname() erzeugen, so müssen wir einen parameterlosen Standard-Konstruktor per Hand hinzufügen. Dass der Standard-Konstruktor dann nicht angelegt wird, hat seinen guten Grund: Es ließe sich sonst ein Objekt anlegen, ohne dass vielleicht wichtige Variablen initialisiert worden wären.

Wie ein nützlicher Konstruktor aussehen kann

Besitzt ein Objekt eine Reihe von Attributen, so wird ein Konstruktor in der Regel diese Attribute initialisieren wollen. Wenn wir eine Unmenge von Attributen in einer Klasse haben, sollten wir dann auch endlos viele Konstruktoren schreiben? Besitzt eine Klasse Attribute, die durch setXXX()- getXXX()-Methoden gesetzt werden, so ist es nicht unbedingt nötig, dass diese Attribute im Konstruktor gesetzt werden. Ein Standard-Konstruktor, der das Objekt in einen Initialzustand setzt, ist angebracht; anschließend können die Zustände mit den Zugriffsfunktionen verändert werden. Das sagt auch die JavaBeans-Konvention. Praktisch sind sicherlich auch Konstruktoren, die die häufigsten Initialisierungsszenarien abdecken. Das Punkt-Objekt der Klasse java.awt.Point lässt sich mit dem Standard-Konstruktor erzeugen, aber auch mit einem parametrisierten, der gleich die Koordinatenwerte entgegennimmt.

Besitzt ein Objekt Attribute, die nicht über Setze-Funktionen modifiziert werden können, diese Werte aber bei Objekterzeugung wichtig sind, so bleibt nichts anderes übrig, als die Werte im Konstruktor einzufügen. (Eine set-Funktion, die nur einmalig eine Schreiboperation zulässt, ist nicht wirklich schön.) So arbeiten zum Beispiel Werteobjekte, die einmal im Konstruktor einen Wert bekommen und ihn beibehalten. In der Java-Bibliothek gibt es eine Reihe solcher Klassen, die keinen Standard-Konstruktor besitzen, und nur einige parametrisierte, die Werte erwarten. Die im Konstruktor übergebenen Werte initialisieren das Objekt, und es behält diese Werte das ganze Leben lang. Zu den Klassen gehören etwa Color, File, Font und Integer.

Weiterhin ist ein Konstruktor außerordentlich praktisch, der seinesgleichen entgegennimmt. Ein Beispiel: Die Klasse Socke bekommt einen Konstruktor, der eine andere Socke als Parameter entgegennimmt. Auf diese Weise lässt sich eine schon initialisierte Socke als Attributvorlage nutzen. Alle Eigenschaften der existierenden Socke sollen auf die neue Socke übertragen werden. Die Implementierung kann so aussehen:

Listing 6.15 KSocke.java

class KSocke
{
  String farbe;
  int    größe;
  KSocke()
  {
  }
  
  KSocke( KSocke andereSocke )
  {
    farbe = andereSocke.farbe;
    größe = andereSocke.größe;
  }
  
  public String toString()
  {
    return "Farbe: " + farbe + " Größe: " + größe;
  }
  
  public static void main( String args[] )
  {
    KSocke thommysSocke = new KSocke();
    thommysSocke.farbe = "grün";
    thommysSocke.größe = 42;
    System.out.println( thommysSocke );  // Farbe: grün Größe: 42
      
    KSocke estersSocke = new KSocke( thommysSocke );
    System.out.println( estersSocke );   // Farbe: grün Größe: 42
  }
}

6.5.2 Einen anderen Konstruktor der gleichen Klasse aufrufen 

Mitunter werden zwar verschiedene Konstruktoren angeboten, aber nur in einem Konstruktor verbirgt sich die tatsächliche Initialisierung des Objekts. Ein Konstruktor möchte daher einen anderen Konstruktor derselben Klasse - nicht den der Oberklasse - aufrufen, um nicht gleichen Programmcode mehrfach ausprogrammieren zu müssen. Dazu dient wieder das Schlüsselwort this.

class Socke
{
  String farbe;
  Socke( String farbe )
  {
    this.farbe = farbe;     // this ist hier die Referenz
  }
  Socke()
  {
    this( "schwarz" );      // this() leitet an anderen
                            // Konstruktor weiter
  }
}

Die Klasse Socke besitzt zwei Konstruktoren, den Standard-Konstruktor und einen Ein-Parameter-Konstruktor. Wird ein neues Objekt mit new Socke() aufgebaut, wird der Standard-Konstruktor aufgerufen und ihm anschließend die Farbe Schwarz im parametrisierten Konstruktor übergeben - Standardsocken sind einfach schwarz.

Natürlich stellt sich die Frage, warum wir denn einen zweiten Aufruf starten. Viel einfacher wäre doch Folgendes für den Standard-Konstruktor:

Socke()
{
  farbe = "schwarz";
}

Das ist in der Tat weniger zu schreiben und auch schneller ausgeführt, doch diese Implementierung hat einen großen Nachteil. Nehmen wir an, wir hätten zehn Konstruktoren für alle erdenklichen Fälle in genau diesem Stil implementiert. Tritt der unerwünschte Fall ein, dass wir auf einmal in jedem Konstruktor etwas initialisieren müssen, so muss der Programmcode, etwa ein Aufruf der Methode init(), in jedem der Konstruktoren eingefügt werden. Dieses Problem umgehen wir einfach, indem wir die Arbeit auf einen speziellen Konstruktor verschieben. Ändert sich nun das Programm in der Weise, dass überall beim Initialisieren zusätzlicher Programmcode ausgeführt werden muss, ändern wir eine Zeile in dem konkreten von allen benutzten Konstruktor. Damit fällt für uns wenig Änderungsarbeit an: unter softwaretechnischen Gesichtspunkten ein großer Vorteil. Überall in den Java-Bibliotheken lässt sich diese Technik wieder erkennen. Ein schönes einfaches Beispiel ist etwa die Point-Klasse. Ein Ausschnitt:

public class Point extends Point2D implements
  java.io.Serializable
{
  public int x, y;
  public Point() {
    this(0, 0);
  }
  public Point(Point p) {
    this(p.x, p.y);
  }
  public Point(int x, int y) {
    this.x = x;
    this.y = y;
  }
}

Einschränkungen

Beim Aufruf eines anderen Konstruktors mittels this() gibt es zwei wichtige Beschränkungen:

class Socke
{
  final int ringelAnzahl = 4;
  static final int RINGEL_ANZAHL = 4;
  Socke( String g, int anzRing ) { ... }
  
  Socke( String f )
  {
//    this( f, ringelAnzahl );      // nicht erlaubt
    this( f, RINGEL_ANZAHL );       // das geht stattdessen
  }
}

Da Objektvariablen bis zu einem bestimmten Punkt noch nicht initialisiert sind, lässt uns der Compiler nicht darauf zugreifen - nur statische Variablen sind als Übergabeparameter erlaubt.

6.5.3 Initialisierung der Objekt- und Klassenvariablen 

Eine wichtige Eigenschaft von Programmiersprachen ist ihre Fähigkeit, keine uninitialisierten Zustände zu erzeugen. Bei lokalen Variablen achtet der Compiler auf die Belegung, ob vor dem ersten Lesezugriff schon ein Wert zugewiesen ist. Bei Objektvariablen und Klassenvariablen haben wir bisher festgestellt, dass automatisch die Variablen mit 0 oder mit einem Wert belegt werden. Wir wollen jetzt sehen, wie dies genau funktioniert.

Objektvariablen

Wenn der Compiler eine Klasse mit Objekt- oder Klassenvariablen sieht, dann müssen diese Variablen an irgendeiner Stelle initialisiert werden. Werden sie einfach definiert und nicht mit einem Wert initialisiert, so regelt die virtuelle Maschine die Vorbelegung. Spannender ist der Fall, wenn den Variablen explizit ein Wert zugewiesen wird (der auch 0 sein kann). Dann erzeugt der Compiler automatisch ein paar zusätzliche Zeilen.

Beachten wir dies zuerst für Objektvariablen.

Listing 6.16 InitObjectVariable.java

class InitObjectVariable
{
  int j = 1;
  InitObjectVariable()
  {
  }
  InitObjectVariable( int j )
  {
    this.j = j;
  }
  InitObjectVariable( int x, int y )
  {
  }
}

Die Variable j wird mit 1 belegt. Es ist wichtig zu wissen, an welcher Stelle Variablen ihre Werte bekommen. So erstaunlich das klingt, aber die Zuweisung findet im Konstruktor statt. Das heißt, der Compiler wandelt das Programm bei der Übersetzung eigenmächtig wie folgt um:

class InitObjectVariable
{
  int j;
  InitObjectVariable()
  {
    j = 1;
  }
  InitObjectVariable( int j )
  {
    this.j = 1;
    this.j = j;
  }
  InitObjectVariable( int x, int y )
  {
    j = 1;
  }
}

Wir erkennen, dass die Variable wirklich nur dann initialisiert wird, wenn auch ein Konstruktor aufgerufen wird. Die Zuweisung steht dabei in der ersten Zeile. Dies kann zur Falle werden, denn problematisch ist etwa die Reihenfolge der Belegung.

Manuelle Nullung

Genau genommen initialisiert die Laufzeitumgebung die Variable erst einmal mit 0 und dann später mit einem Wert. Daher ist die Initialisierung auch ein bisschen langsamer, wenn die Nullung von Hand zusätzlich eingebaut wird, also etwa so:

class InitNullUnnötig
{
  int i = 0;
}

Denn der Wert ist automatisch mit 0 belegt, und der Compiler würde in jeden Konstruktor die Zuweisung i=0 einsetzen.¹

Klassenvariablen

Abschließend bleibt die Frage, wo Klassenvariablen initialisiert werden. Im Konstruktor macht dies keinen Sinn, da für Klassenvariablen keine Objekte angelegt werden müssen. Dafür gibt es den static{}-Block. Dieser wird immer dann ausgeführt, wenn der Klassenlader eine Klasse in die Laufzeitumgebung geladen hat. Für eine statische Variable i=2 ergibt sich dann folgendes Bild, das der Compiler wieder selbstständig bei der Übersetzung einfügt:

class StaticInit
{
  static int i;
  static
  {
    i = 2;
  }
}

6.5.4 Finale Werte im Konstruktor setzen 

Bisher sind wir davon ausgegangen, dass finale Werte immer dann gesetzt werden müssen, wenn die Variable deklariert wird. Diese Ansicht können wir etwas erweitern. Bedenken wir, dass alle statischen Variablen in static-Blöcken und alle Objektvariablen in Konstruktoren initialisiert werden, so gilt dies ebenso für finale Werte. Auch sie werden im Konstruktor gesetzt. Wichtig ist, dass finale Werte auf jeden Fall gesetzt werden und dass nur ein Schreibzugriff möglich ist. Mit diesem Vorgehen lassen sich auch »variable« Konstanten angeben:

class VariableConstant
{
  final static int MWST;   // hier steht nicht = irgendwas
  final String ISBN;       // hier auch nicht.
  static
  {
    if ( 2 > 1 )
      MWST = 7;
    else
      MWST = 16;
  }
  VariableConstant()
  {
    ISBN = "3572100100";
  }
  public static void main( String args[] )
  {
    System.out.println( MWST );                         // 7
    System.out.println( new VariableConstant().ISBN );  // 3572100100
  }
}

Der Nachteil dieser Variante ist natürlich, dass die Lesbarkeit leidet. Der Leser muss sich mitunter erst durch viele Zeilen Quellcode kämpfen, bis er weiß, wie der Wert belegt ist. Daher sollte diese Programmiertechnik nur zum Einsatz kommen, wenn der Wert nicht direkt berechnet werden kann.

6.5.5 Exemplarinitialisierer (Instanzinitialisierer) 

Neben den Konstruktoren haben die Sprachschöpfer eine weitere Möglichkeit vorgesehen, um Objekte zu initialisieren. Diese Möglichkeit wird insbesondere bei anonymen, inneren Klassen wichtig, also bei Klassen, die sich in einer anderen Klasse befinden.

Ein Exemplarinitialisierer ist ein Konstruktor ohne Namen. Er besteht in einer Klassendefinition nur aus einem Paar geschweifter Klammern und gleicht einem statischen Initialisierungsblock ohne das Schlüsselwort static:

class Klasse
{
  {
     // Exemplarinitialisierer.
  }
}

In einer Klasse können mehrere Exemplarinitialisierer auftauchen. Die Exemplarinitialisierer werden der Reihe nach durchlaufen, und zwar vor dem eigentlichen Konstruktor. Damit gilt, dass Objektvariablen noch nicht zwingend initialisiert sind, da einige erst durch den Konstruktor belegt werden.

6.5.6 Zerstörung eines Objekts durch den Müllaufsammler 

Glücklicherweise werden wir beim Programmieren von der lästigen Aufgabe befreit, Speicher von Objekten freizugeben. Wird ein Objekt nicht mehr referenziert, dann wird der Garbage-Collector² aufgerufen, und dieser kümmert sich um alles Weitere - der Entwicklungsprozess wird dadurch natürlich vereinfacht. Der Einsatz eines GCs verhindert zwei große Probleme:

Ein Objekt kann gelöscht werden, aber die Referenz existiert noch (engl. dangling pointer).

Kein Zeiger verweist auf ein bestimmtes Objekt, dieses existiert aber noch im Speicher (engl. memory leaks).

Dem GC wird es leicht gemacht, wenn nicht mehr benötigte Referenzen sofort mit null überschrieben werden (objRef = null), denn dann weiß der GC, dass zumindest ein Verweis weniger auf das Objekt existiert. War es der letzte Verweis, kann der GC dieses Objekt sofort entfernen, wenn weiterer Speicherplatz für neue Objekte benötigt wird.

Prinzipielle Arbeitsweise

Der GC erscheint hier als ominöses Ding, welches clever die Objekte verwaltet. Doch was ist der GC? Implementiert ist er als Thread (unabhängiger Prozess) mit niedriger Priorität. Er verwaltet die Wurzelobjekte, von denen aus das gesamte Geflecht der lebendigen Objekte erreicht werden kann. Dazu gehören die Wurzel des ThreadGroup-Baums und die lokalen Variablen aller aktiven Methodenaufrufe (Laufzeitkeller aller Threads). In regelmäßigen Abständen werden nicht benötigte Objekte markiert und entfernt.

Effiziente GCs sind Teil der Forschung. Sun verwendet unter anderem einen sehr einfachen Algorithmus, der unter dem Namen »Mark and Sweep« bekannt ist. Das Markieren der nicht mehr verwendeten Objekte nimmt dabei die meiste Zeit in Anspruch. In der Implementierung des GCs unterscheiden sich die Java-Interpreter der verschiedenen Anbieter. So verwendet die VM von Microsoft eine effizientere Strategie zum Erkennen und Entfernen der Objekte. Sie verwendet einen modifizierten »Stop and Copy«-Algorithmus, der schneller ist als die gewöhnlichen GC-Strategien. Somit wirbt Microsoft nicht ohne Grund damit, dass ihre VM einen Geschwindigkeitsvorteil von einem Faktor 2-4 gegenüber der frühen Sun-Implementierung - Stand 1.1 - besitzt (natürlich nicht immer hundertprozentig kompatibel). Insbesondere ist das Anlegen von Objekten bei Microsofts VM flott.

Mittlerweile ist auch das Anlegen von Objekten unter der Java VM von Sun dank der Hot-Spot-Technologie schneller geworden. Hot-Spot ist seit Java 1.3 fester Bestandteil des Java SDK. Hot-Spot verwendet einen generationenorientierten GC, der ausnutzt, dass zwei Gruppen von Objekten mit deutlich unterschiedener Lebensdauer existieren. Die meisten Objekte sterben sehr jung, die wenigen überlebenden Objekte werden hingegen sehr alt. Die Strategie dabei ist, dass Objekte im »Kindergarten« erzeugt werden, der sehr oft nach toten Objekten durchsucht wird und in der Größe auf etwa 64 k beschränkt ist. Überlebende Objekte kommen nach einiger Zeit aus dem Kindergarten in eine andere Generation, die nur selten vom GC durchsucht wird. Damit folgt der GC der Philosophie von Auffenberg, der sagte: »Verbesserungen müssen zeitig glücken; im Sturm kann man nicht mehr die Segel flicken«. Das heißt, der GC arbeitet ununterbrochen und räumt auf. Er beginnt nicht erst dann mit der Arbeit, wenn es zu spät ist und der Speicher schon voll ist.

6.5.7 Implizit erzeugte String-Objekte 

In den bisherigen Beispielen haben wir gesehen, dass ein Objekt mit dem new-Operator gebildet wird. Es gibt aber noch eine versteckte Objekterzeugung bei Zeichenketten. Betrachten wir folgende Zeilen:

Date d = new Date();
String s = "Chicken Run";
String t = "Chicken Run";

Beim Datum erzeugten wir ausdrücklich ein neues Date-Objekt. Die zweite Zeile erzeugt jedoch implizit ein String-Objekt, das das angegebene Zeichenketten-Literal speichert. In der dritten Zeile gilt nun etwas Besonderes. Um dies zu erkennen, müssen wir wissen, dass Zeichenketten-Literale in einem Konstantenpool der virtuellen Maschine gehalten werden. Gleiche Zeichenketten bei String-Objekten für Literale (und nur dort) werden daher auf die gleichen Referenzen gelenkt. Genau in diesem Fall lassen sich mit dem Vergleichsoperator = = die Zeichenketten vergleichen. In der dritten Zeile wird demnach also kein neues String-Objekt erzeugt, sondern die Referenz t ist mit der von s identisch.

Der letzte Fall einer impliziten Objekterzeugung hat wieder mit Zeichenketten zu tun: Der Plus-Operator zur Konkatenation von nicht konstanten Zeichenketten (konstante Zeichenketten werden vom Compiler zusammengefügt) erzeugt einen StringBuffer, dessen Bausteine mit append() angehängt werden. Nach der Aneinanderreihung wird der StringBuffer wieder zu einem String konvertiert:

String s = "Peter Lord " + '&' + " Nick Park";  // 3
String s = new StringBuffer("Peter Lord ").append('&').
             append(" Nick Park").toString();

6.5.8 Zusammenfassung: Konstruktoren und Methoden

Methoden und Konstruktoren haben einige Gemeinsamkeiten in der Signatur, aber auch einige wichtige Unterschiede wie den Rückgabewert oder den Gebrauch von this und super. Die folgende Tabelle fasst die Unterschiede und Gemeinsamkeiten noch einmal kompakt zusammen:⁴

¹Wir wollen hier den Fall, dass der Konstruktor der Oberklasse i einen Wert ungleich 0 setzt, nicht betrachten.

²Lange Tradition hat der Garbage-Collector unter LISP und unter Smalltalk, aber auch Visual Basic benutzt einen GC.

³Die Erfinder von Wallace & Gromit und Chicken Run. Für den neuen Film haben 40 Kneter in drei Jahren zwei Tonnen Plastilin geformt.

⁴Schon seltsam, dass synchronized nicht erlaubt ist, aber ein Konstruktor ist implizit synchronized.