[Ben]

Hallo,
okay .. stelle ich hier mal meine erste Fachfrage bzgl. Java.

Es geht um etwas, was ich soeben gefunden habe ... Destruktoren in Java.
Guido Krüger schreibt.

Neben Konstruktoren, die während der Initialisierung eines Objekts aufgerufen werden, gibt es in Java auch Destruktoren. Sie werden unmittelbar vor dem Zerstören eines Objekts aufgerufen.

Ein Destruktor wird als geschützte (protected) parameterlose Methode mit dem Namen finalize definiert:

protected void finalize()
{
   ...
}

Da Java über ein automatisches Speichermanagement verfügt, kommt den Destruktoren hier eine viel geringere Bedeutung zu als in anderen objektorientierten Sprachen. Anders als etwa in C++ muß sich der Entwickler ja nicht um die Rückgabe von belegtem Speicher kümmern; und das ist sicher eine der Hauptaufgaben von Destruktoren in C++.

Tatsächlich garantiert die Sprachspezifikation nicht, daß ein Destruktor überhaupt aufgerufen wird. Wenn er aber aufgerufen wird, so erfolgt dies nicht, wenn die Lebensdauer des Objektes endet, sondern dann, wenn der Garbage Collector den für das Objekt reservierten Speicherplatz zurückgibt. Dies kann unter Umständen nicht nur viel später der Fall sein (der Garbage Collector läuft ja als asynchroner Hintergrundprozeß), sondern auch gar nicht. Wird nämlich das Programm beendet, bevor der Garbage Collector das nächste Mal aufgerufen wird, werden auch keine Destruktoren aufgerufen. Selbst wenn Destruktoren aufgerufen werden, ist die Reihenfolge oder der Zeitpunkt ihres Aufrufs undefiniert. Der Einsatz von Destruktoren in Java sollte also mit der nötigen Vorsicht erfolgen.

Quelle: Handbuch der Java Programmierung / www.javabuch.de

Jou. Also da steht kurz, dass man gar nicht sicherstellen kann, dass der Destruktor überhaupt aufgerufen wird.
Darf ich mal ganz kurz fragen, warum es dann überhaupt so etwas wie einen Destruktor gibt?

Da steige ich nämlich nicht wirklich hinter.

Danke Euch.

Grüße Ben.

[mr1st]

Grob gesagt könnte man sagen, dass Sun die völlig umsonst reingetan hat.
In anderen Programmiersprachen ist es üblich, in den Desruktoren die Ressourcen freizugeben, in Java werden dafür aber meist eigene Methoden verwendet, da die Destruktoren von Java nicht brauchbar dafür sind (zB die close() Methoden bei Streams).
Vielleicht hat Sun die nur reingegeben, weil ja die meisten anderen Programmiersprachen auch welche haben. Effektiv haben sie aber, wie gesagt, gar keinen Wert.

Am besten gar nicht verwenden, einfach deren Existenz ingorieren.

MfG

[Ben]

Am besten gar nicht verwenden, einfach deren Existenz ingorieren.

Hm. Ich habe befürchtet, dass so etwas kommt
Ist ja irgendwie nicht befriedigend, oder?

Es ist so viel Zeug als "deprecated" markiert, warum werden dann die Destruktoren nicht auch einfach entfernt?

Hm. Alles unverständlich ... finde ich ..

Also zum einen: Was sicher schon klar geworden ist: In Java spielen Destruktoren bei weitem nicht so eine wichtige Rolle wie z.B in C++. Dies liegt an dem GC (Garbage Collector).
Willst du nun das vor der tatsächlichen "Zerstörung" eines Objekts best. Operationen noch ausgeführt werden, so kannst du eine finalize() Methode implementieren und in dieser entsp. Schritte durchführen.

Allerdings steht im Handbuch ja auch das es nicht sichergestellt ist das der Compiler tatsächlich finalize() aufruft.

Ich denke Destruktoren sind in einigen wenigen Bereichen vielleicht ganz sinnvoll, aber im normalen Gebrauch nicht. Ist zumindest meine Meinung.

Wenn du eine Referenz auf ein Objekt hast, dann weiss diesem lieber "null" zu um es zu "löschen", da Objekte automatisch gelöscht werden wenn keine Referenz mehr darauf existiert.

[Ben]

Ich habe schon verstanden, was da steht. Ist ja nicht wirklich anspruchsvoll
Mir ging es mehr um den Sinngehalt der Destruktoren, der aber ja anscheinend nicht wirklich vorhanden ist.

Grüße Ben.

Ich habe nicht bezweifelt das du das verstanden hast, nur vielleicht liest sich jemand das hier durch der noch nichts davon gehört hat .

Wie gesagt, abgesehen davon das du vielleicht in finalize() best. Operationen durchführen willst (da deine Objekte Netzwerkverbindungen geöffnet haben etc.), kannst du dort z.B. diese schließen oder andere schöne Dinge anstellen.

Mich hat diese Antwort auch nicht befriedigt , aber unser Prof konnte auch nicht erkären warum die Leute von SUN es nun (so) implementiert haben.

[Ben]

Wie gesagt, abgesehen davon das du vielleicht in finalize() best. Operationen durchführen willst (da deine Objekte Netzwerkverbindungen geöffnet haben etc.), kannst du dort z.B. diese schließen oder andere schöne Dinge anstellen.

An das Schließen von solchen Verbindung hatte ich auch erst gedacht, allerdings ist es meiner Ansicht nach sicherlich sinnvoller, wenn diese Verbidnung explizit gekappt werden. Denn wie ja oben steht kann man gar nicht sicherstellen, dass die Destruktoren überhaupt laufen.

Man könnte maximal in Destruktoren überprüfen, ob nicht doch noch irgendwas aufgrund irgendwelcher fehlerhafter Operationen im Programm zu "schließen" etc. ist und dann Anweisungen ausführen, die eben dies tun.

Das wäre dann z.B. noch eine Absicherung, die zwar nicht immer verfügbar ist, aber eventuell das Ausmaß von Fehlern reduzieren kann.

Was anderes fällt mir beim besten Willen nicht ein.

Grüße Ben.

An das Schließen von solchen Verbindung hatte ich auch erst gedacht, allerdings ist es meiner Ansicht nach sicherlich sinnvoller, wenn diese Verbidnung explizit gekappt werden. Denn wie ja oben steht kann man gar nicht sicherstellen, dass die Destruktoren überhaupt laufen.

Da stimm ich dir zu, es ist sicher besser so schon zu probieren die Verbindungen explizit zu trennen. Vielleicht kann einer von den zuständigen Programmierern von SUN hier mal gerad ne Stellungnahme posten ? *g*

Wäre auch froh wenn jemand mal hieb und stichfeste argumente liefern könnte.

[Ben]

Vielleicht kann einer von den zuständigen Programmierern von SUN hier mal gerad ne Stellungnahme posten ? *g*

Ähm. Nee. *gg* In diesem Leben wohl nicht mehr.

Gut. Ich habe mal etwas in den Foren auf SUN rumgestöbert. Und da steht genau das selbe, was wir hier auch von uns gegeben haben.

Selbst der Aufruf von System.gc(); reicht nicht aus um abzusichern, dass der GarbageCollector anfängt u.a. Destruktoren aufzurufen.

Nunja. Da muss ich mich wohl mit dieser unbefriedigenden Antwort begnügen.

Danke und Grüße Ben.

Hi Ben,

wie Du vorhin schon (in einem Nebensatz)festgestellt hast:

Man braucht den finalize praktisch nur zum Aufräumen von Ressourcen, wenn jemand vergessen hat, close() aufzurufen. Im Client-Betrieb kann vielleicht darauf verzichten, aber bei Server-Betrieb passiert eine Garbage-Collection schon mal öfter... Und im Server-Betrieb ist so eine Selbstheilung echtes Gold wert.

Ach übrigens: Wenn man eine gc() braucht: Mehrfach aufrufen und zwischendurch warten reicht meist aus...

... und Du hast vergessen, dass man in einem finalizer UNBEDINGT super.finalize aufrufen MUSS.

protected void finalize() {
  try {
     // ... hier den eigenen Code eingeben
  } finally {
     super.finalize();
  }
}

Viel Erfolg beim eigenen finalizer...

[Ben]

... und Du hast vergessen, dass man in einem finalizer UNBEDINGT super.finalize aufrufen MUSS.

protected void finalize() {
  try {
     // ... hier den eigenen Code eingeben
  } finally {
     super.finalize();
  }
}

Viel Erfolg beim eigenen finalizer...

Warum muss man das?
Ich dachte, dass die finalize()-Methode aus Objekt leer implementiert .. .. hab ich da eine falsche Information?

Danke ..

... solange Du Dich von Object ableitest stimmt das.

Aber Du leitest Dich nicht unbedingt von Object ab und wenn Du das nicht tust und in Deinem Code eine Exception geworfen wird, werden die "Parent"-Klassen nicht finalisiert.

Und den Fehler such dann mal schön...

[Ben]

Okay. Ist verständlich, da ich ja normalerweise auch nicht von Object ableite.
Jo, okay. Da werde ich meinen FAQ-Beitrag nochmals überarbeiten.

Danke.
Grüße Ben.

[Ben]

Okay.
Ich hoffe, dass das richtig und einigermaßen verständlich zusammenfasst wurde.
http://www.php-info.org/ftopic96.html

Grüße Ben ;_)

... normalerweise schreibt man im Finalizer Code z.B. wie folgt:

protected void finalize() { 
  try { 
     if (!closed)
       close(); 
  } finally { 
     super.finalize(); 
  } 
}

Dadurch wird beim Aufräumen die close() Methode aufgerufen, wenn das nicht schon ohnehin passiert ist.

[Sym]

Ganz ehrlich?

Der Text klingt ein wenig wischi-waschi. So als würder der GC selber handeln - nach dem Zufallsprinzip. Dem ist aber ja nun nicht so. Er kommt, wenn der Rechner genug Kapazitäten dafür frei hat. Notfalls müsste man das Programm anhalten, damit der GC aufräumen kann.

Und die Stelle "GC mehrmals aufrufen und dazwischen warten" klingt auch sehr komisch. Gut, er ist dann öfter in der Schleife und hat somit eine höhere Wahrscheinlichkeit dran zu kommen, aber ob das der richtige Weg ist?

Sonst ist es aber ok.

[Ben]

Wo wird denn die Variable "closed" definiert?

@Ben: Das war ein Beispiel. Wenn man close() mehrfach schadlos hinterienander aufrufen kann, kann man auch einfach nur close() angeben.

@sym: Die Tücke ist, dass zum einen genügend Kapazität frei sein muß, damit mit System.gc() der Garbage Collector überhaupt losläuft und zum anderen es nicht zwingend gesagt ist, das in einem Lauf alle Objekte behandelt werden. Deshalb muß man - um sicherzugehen - den gc mehrfach aufrufen mit Pausen dazwischen (wegen der Kapazität). Und wann der GC ansonsten aufgerufen wird, ist natürlich determiniert, aber von GC zu GC und von JVM zu JVM unterschiedlich.