Hallo zusammen,
reicht es zum zerstören einer Hashtable mit komplexen Objekten, die Hashtable auf Null zu setzen
oder muss man zuerst mit foreach jedes Objekt zerstören? (auf Null setzen, Disposen)
Ich meine, wenn ich zügig und unabhängig vom Garbage-Collector zerstören will.
Wo kann man so etwas nachlesen - oder, wie kann man es ausprobieren?
Meine Anwendungen bleiben oft längere Zeit relativ "speicherfressend / -reservierend".
Ich weiß keine keinen Ansatz, dass Objekte-zerstören vernünftig zu kontrollieren.
Der schlaue Garbage-Collector macht irgendwas, irgendwann!?
danke
vega
Ich hatte eine Anwendung bei der sicherheitskritische Daten möglichst kurz im Speicher gehalten werden sollten.
Ich habe das Objekt welches die Daten repräsentiert auf null gesetzt und anschließend mit GC.Collect() einsameln lassen.
Ob du jedes Objekt einzeln "nullen" musst, kann ich nicht sagen. Aber du könntest es ausprobieren in dem du für jedes Objekt in der Hashtable einen Desktruktor definierst der eine Debug-Meldung ausgibt.
Hallo vega,
um das Freigeben von verwalteten Objekte wie Hashtable musst du dich gar nicht kümmern. Überlasse das dem GC.
herbivore
Hallo Herbivore,
Hatten wir nicht einmal eine Diskussion bezüglich Destruktoren und das vernachlässigen des GC?
Hallo Sera,
es gibt mehrere Threads zu dem Thema GC - mit und ohne Bezug zu Destruktoren ... wobei im konkreten Fall Destruktoren nicht mal eine Rolle spielen.
herbivore
Original von tscherno
Ich habe das Objekt welches die Daten repräsentiert auf null gesetzt und anschließend mit GC.Collect() einsameln lassen.
Hallo zusammen,
ich setze jetzt die Hashtable auf Null und rufe GC.Collect() auf.
Nachdem damit alle Verweise auf meine Objekte weg sind, gehe ich davon aus, dass der GC alles aufräumt.
danke Euch!
vegaS
PS:
ich habe es ausprobiert in einem Test-Projekt:
nach dem Nullsetzen der Hashtable passiert erst mal nix,
weil sich der GC sich noch nicht genötig sieht.
Nach GC.Collect() werden sofort alle Objekte wild durcheinander
zerstört. cool!
danke Euch!
vega
P.P.S:
ABER
ich setze jetzt meine Klasse (intern die Hashtable) zum löschen auf null.
Der Destructor wird auch aufgerufen und setzt (unnötig) die interne Hashtable auf null.
Mit dem nächsten GC.Collect() werden aber NICHT die Objekte in der Hashtable zerstört,
wie ich es erwartet hätte!?
Sondern erst beim verlassen des Programms.
!?
Es wäre interessant zu erfahren ob die in der Hashtable gehosteten Objekte über eine Disposeimplementierung verfügen.
ja, die Klassen sind alle disposable.
ich habe es in einem kleinen Projekt probiert.
Der ganze Baum wird sauber zerstört !?
(übrigens unabhängig von Dispose() )
Ich weiß nicht, wo mein Fehler lag.
Irgendwo muss ein Verweis auf einen Knoten stehen geblieben sein.
what ever ...
danke!
Dunkel wars:
Das Zerstören der Liste, hindert den GC am Zerstören der Inhalte.
DH: das Ding hat keinen Grund tiefer zu gehen. (Natürlich nur vor dem Tod der Hostanwendung, echte Löcher gibts nicht). Aber eine App reicht oft aus..
Häääääää????
@ikaros: Ich versteh nicht was du meinst.
Die GC sammelt doch alle Objekte auf und schmeist dann die herraus, zu denen noch eine Referenz existiert.
Wenn also die Referenzen, welche die Hashtable, hält ungültig werden (zerstören der Hashtable), werden auch alle nicht anderweitig referenzierten Objekte ungültig.
Wenn nicht, wär das ziemlich übel für mich (bin nämlich für die Erzeugung, Verwaltung und Zerstörung aller resourcenfressenden Persistenz-Objekte unsere Anwendung zuständig) panik!
Dein Erschrecken versteh gut.
Ging mir ähnlich als ich einen bestimmten Artikel las.
Aber bitte reagier nicht über. Ich muss das auch mal verdauen bevor ich's erklären kann.
Vielleicht reagier nur ich über...
Erstmal prüfen...
Fakt ist, ich hab so was in einem Fachmagazin gelesen.
(Um dich zu beruhigen: es ging um statische Listen, also nicht unbedingt ganz so ernst).
*Schweiß von der Stirn wisch* Phuuuu.
Hallo zusammen,
wenn man die letzte Referenz auf die Hashtable entfernt, dann kann die Hashtable vom GC aufgeräumt werden. Wann er das tut steht auf einem anderen Blatt. Wenn es auf die Objekte, die in der Hashtable enthalten sind, keine anderen Referenzen mehr gibt, können auch diese vom GC aufgeräumt werden. Wann er das tut steht auf einem anderen Blatt. Alle anderen Aussagen halte ich für, sorry, Quatsch.
herbivore
hallo,
mit GC.Collect(); sage ich dem GC, dass er sich, sorry, vedammt noch mal die Zeit nehmen soll.
Bei mir scheint es tatsächlich so, dass sich eine
foreach (clsB tmpB in clsA.getBs()) {
// ... tolle Sachen mit tmpB
}
// getBs liefert eine Hashtable auf clsBs zurück :-)
den Verweis hält, obwohl ich ausserhalb und nach der Klammer zerstöre.
Zumindest räumt der GC ohne _foreach _schon mal besser auf. !?
vega
Hallo vega,
ich kann nur wiederholen, was ich heute schon an anderer Stelle geschrieben habe: Dispose von MarshalByRefObject
Du musst dich um das Aufräumen/Zerstören/Löschen von verwalteten Objekten gerade nicht mehr kümmern und solltest es auch nicht tun.
herbivore
Auch GC.Collect erzwingt nicht notwendigerweise, dass die Objekte entsorgt werden. Wenn Du Pech hast, sind sie nach wie vor im Speicher, nur halt im GC als eine Generation "älter" markiert ...
Auch GC.Collect erzwingt nicht notwendigerweise, dass die Objekte entsorgt werden. Wenn Du Pech hast, sind sie nach wie vor im Speicher, nur halt im GC als eine Generation "älter" markiert ...
Aber wenn keine Referenzen mehr auf das Objekt vorhanden Sind, müsste GC.Collect() es doch eigentlich einsameln, weil die Genration ja nur erhöht wird wenn ein Objekt eine Collection überlebt (d.h. noch Referenziert wird). Oder gibt es da noch andere Faktoren die zu berücksichtigen sind?
Du musst dich um das Aufräumen/Zerstören/Löschen von verwalteten Objekten gerade nicht mehr kümmern und solltest es auch nicht tun.
Währe ein unterdrücken des Collectors bei zeitkritischen Programmteilen angebracht?
Hallo tscherno,
Währe ein unterdrücken des Collectors bei zeitkritischen Programmteilen angebracht?
für zeitkritische Anwendung sind Windows/C#/.NET vielleicht eh nicht das richtige.
herbivore