Re: Richtige Zerstörung von eigenen Objekten

From: Stefan Leiber (sleiber_at_webhomer.zzn.com)
Date: 08/02/04 

Date: Mon, 2 Aug 2004 02:29:34 -0700

Natürlich sind meine Klasse keine sehr komplexen Klassen.
Es sind recht einfache Klassen.

Darunter fällt eine Klasse für Datenbankoperationen, eine
zum Erstellen eines SQL-Befehl und eine klasse mit
allgemeinen Prozeduren und Funktionen + plus die weiteren
Klassen für die einzelnen Formularen.

Also das heisst dann, wenn ich es richtig verstanden habe,
das ich direkt keine Speicher freigeben kann. Bei C++ ist
mir dies doch direkt möglich, hier wird diese Arbeit von
dem Garbage Collector übernommen der in gewissen
Zeitabständen die Klasseninstanzen prüft und dann gegebenen
falls freigbt.

Wenn ich jetzt aber in meiner Klasse eine
Finalize-Methode() habe und diese nach der Verwendung des
Objektes aufrufe, wird diese in der Garbage Collection
vermekrt (Mit einem sogenannten HEAP?) und führt dazu das
das der Speicher dieser Instanz schneller freigegeben wird,
beeinträchtig aber wiederum die Leistung des Programmes.

Wie müsste dann der Aufbau der Klasse sein, damit die
Finalize-Methode aufgerufen und durchgefuehrt werden kann.
In einem meiner Bücher "ASP.NET Developer´s Guide" steht
drin, das es dafür schon Destruktoren zu Verfügung stehen,
nämlich "Destruct". Kann ich diese dafür verwenden ? Oder
ist dies wieder was ganz anderes und hat mit dieser Sache
nichts am Hut :).

Und was mir leider auch noch nicht ganz klar ist der
Unterschied zw. Finalize und Dispose.

ich hoffe die jetzt nicht mit Fragen zu überschlagen, würde
 nur gerne das Grundprinzip der Objektzerstörung besser
verstehen um zu wissen wie ich dies korrekt einsetze

Danke & Gruss Stefan

>-----Originalnachricht-----
>Stefan Leiber wrote:
>....
>> ich programmiere gerade meine eigene Klassen. Soweit
>> klappen die Klassen auch gut. Nur ist meine Frage wie ich
>> diese Klappen nachdem benutzen, wieder richig zerstöre [?]
>>
>> Was muss ich da genau tuen, damit diese vom Speicher wieder
>> freigegeben werden [?] Wird dies vom Garbage Collector
>> übernommen [?]
>....
>
>Stafan,
>ob und was zu tun ist, hängt von den Innereien deiner
Klassen ab.
>
>Prinzipiell kannst du selbst explizit keinen Speicher
freigeben. Das kann
>nur der Garbage Collector (GC).
>
>Der GC prüft bei Bedarf jede Klasseninstanz, ob es
Verweise auf diese
>Klasseninstanz gibt. Wenn es keinen Verweis mehr gibt,
dann ruft der GC die
>Finalize-Methode der Klasse auf, auf die kein Verweis mehr
bestht. Jede
>Klasse besitzt eine Finalize-Methode, da jedes Objekt vom
System.Object
>diese Methode erbt. Nach dem Aufruf der Finalize-Methode
wird der Speicher
>freigegeben.
>
>Um also Speicher freizugeben, sind zuerst alle Verweise
auf die nicht
>benötigten Klasseninstanzen zu zerstören (auf Nothing setzen).
>
>Eine Klasse kann das IDisposable-Interface implementieren.
Das ist zwingend
>erforderlich, wenn in einer Klasseninstanz Resourcen
freizugeben sind, die
>nicht vom Framework überwacht werden können und die
deshalb nach der
>Zerstörung eines Objektes "in der Luft hängen bleiben", da
keine Verweise
>auf diese "externen Ressourcen" mehr verfügbar sind. Ganz
schlimm wird es,
>wenn diese "externe Ressource" eine Callback-Routine
aufruft, die nach
>Zerstörung eines Objektes nicht mehr im Speicher vorhanden
ist, aber
>aufgerufen, was meist zu einem Programmabsturz führt.
"Externe Ressourcen"
>sind beispielsweise Datei-Handles, die mit einem Aufruf
von Dispose
>(spätestens aus Finalize) freizugeben sind.
>
>Ansonsten bewirkt der Aufruf von Dispose einer Instanz
eine Mitteilung an
>den GC, dass beim nächsten Lauf des GC der von dieser
Instanz belegte
>Speicherplatz freigegeben werden kann. Um eine Belastung
durch mehrfache
>Läufe des GC bei ineinander geschachtelten
Klasseninstanzen zu vermeiden,
>empfielt es sich, in diesen Fällen Dispose entsprechend
geschachtelt
>aufzurufen und ggf. sogar mit SupressFinalize die Arbeit
des GC zeitweilig
>zu unterdrücken.
>
>Besonderheiten sind bei gemeinsam genutzten Komponenten zu
beachten.
>
>Peter
>
>.
>

Relevant Pages

  • Re: wie Array =?ISO-8859-15?Q?f=FCr_statische_Methoden?=
    ... Kriterien, über die wir uns wohl einigermaßen einig sind, zutreffen dann benutze ich diesen Modifier eben auch, sonst nicht. ... entsprechenden Klasse und die Kostet auf jeden Fall Speicher selbst wenn es keine lokalen Variablen gibt. ... Gerade wenn es mehrere Aufrufer gibt und die immer wieder eine Instace von der Klasse erstellen müssen nur um eine simple Utility-Methode aufzurufen dann belastet das bei Java ja auch noch den GC. ...
    (de.comp.lang.java)
  • Re: Dictionaries - schnell und effizient?
    ... das ich davon ca. 100.000 Stück kurzzeitig im Speicher halten muss und daher nicht eine eigene Klasse schreiben will. ... Ich nehme mal an, du meinst 100.000 IDs. ... "Hashtable" wahrscheinlich nur geringfügig anders verhalten, Dictionary ist halt einfach die typsichere Variante. ... Eine eigene Klasse wollte ich vermeiden weil das ja Overhead bedeutet, aber ich komme dabei aus dem PHP Bereich wo ein array deutlich ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: wie Array =?ISO-8859-15?Q?f=FCr_statische_Methoden?=
    ... entsprechenden Klasse und die Kostet auf jeden Fall Speicher selbst wenn es keine lokalen Variablen gibt. ... Wenn du eine static methode aufrufst musst du auch eine Reference auf dem Stack haben, nämlich die Klasse. ... Probleme als Performanceverlust bzw. -gewinn durch ändern einnes Modifier! ...
    (de.comp.lang.java)
  • Re: Memoryblock
    ... Zugriff über folgendes Konstrukt erhalten: ... Speicher zu verschwenden, ... Am meisten lernt man was über die Funktionsweise einer Klasse, ... Wer Komponenten ohne Quelltext oder richtig miese Komponenten ...
    (de.comp.lang.delphi.misc)
  • Re: Heap betrachten?
    ... Okay, dann kann ich das mit IDisposable mal sein lassen, da es bei mir nur ... Ich habe in die finalize-Methode ein Print.Debug reingeschriegen, ... IDisposable brauchst Du nur um unverwaltete Resourcen freizugeben. ... daher sollte der Nutzer der Klasse Dispose ...
    (microsoft.public.de.german.entwickler.dotnet.vb)