memory leak freak
-
Sobald du foo aufrufst wird die Referenz von bytes auf another_bytes gesetzt und du hast keine referenz mehr auf das alte array, nun hat der GC die Möglichkeit es zu Collecten.
In C# wird Allokierter Speicher von dem GC aufgeräumt sobald es keine Referenz mehr darauf gibt. WeakReference ist da eine Ausnahme.
-
????!!!! schrieb:
memory leak in C#?
Also so abwägig ist das nicht wie Du vielleicht denkst - trotz GC.
Häufiger sind wohl generelle Resourcen Leaks, weil z.B. Dispose() nicht aufgerufen wird.
Simon
-
theta schrieb:
????!!!! schrieb:
memory leak in C#?
Also so abwägig ist das nicht wie Du vielleicht denkst - trotz GC.
Häufiger sind wohl generelle Resourcen Leaks, weil z.B. Dispose() nicht aufgerufen wird.
Simon
Ein nicht augerufenes Dispose führt aber nicht zu einem Leak, weil Dispose spätestens von der GC automatisch aufgerufen wird. Das kann zwar zu Problemen führen, die aber keine leaks sind.
Leaks in C# können dann entstehen wenn man unmanaged resourcen in einer Klasse hat und Dispose nicht, bzw falsch implementiert.
-
loks schrieb:
theta schrieb:
????!!!! schrieb:
memory leak in C#?
Also so abwägig ist das nicht wie Du vielleicht denkst - trotz GC.
Häufiger sind wohl generelle Resourcen Leaks, weil z.B. Dispose() nicht aufgerufen wird.
Simon
Ein nicht augerufenes Dispose führt aber nicht zu einem Leak, weil Dispose spätestens von der GC automatisch aufgerufen wird. Das kann zwar zu Problemen führen, die aber keine leaks sind.
Leaks in C# können dann entstehen wenn man unmanaged resourcen in einer Klasse hat und Dispose nicht, bzw falsch implementiert.
Nö, Dispose wird eben nicht vom GC aufgerufen. Erzeug dir mal ein FileStream, öffne eine Datei, schreib was rein und ruf kein Close/Dispose auf. Nach beendigung des Programms wird weder Dispose noch Close aufgerufen und in der Datei steht nichts drinne.Warum auch sollte sich die Runtime darum kümmern das aufzuräumen was der Entwickler nicht beachtet hat.
-
Leaks in C# können dann entstehen wenn man unmanaged resourcen in einer Klasse hat und Dispose nicht, bzw falsch implementiert.
Leaks sind es dann wenn eine Resource unnötigerweise od. länger als nötig blockiert / offen bleibt.
Ansonsten könnte auch in C++ bei einem vergessenen delete od. CloseHandle(..) nicht von Memory bzw. Resourcen Leak gesprochen werden, denn das OS räumts bei Prozessende wieder auf.
BTW: in C# können auch "Leaks" entstehen, weil Referenzen "ewig" gehalten werden, z.B. im Zusammenhang mit EventHandlern. Es gibt nicht umsonst das "Weak Event Pattern".
Edit:
Weak Event Pattern: http://msdn.microsoft.com/en-us/library/aa970850.aspxSimon
-
Firefighter schrieb:
Nö, Dispose wird eben nicht vom GC aufgerufen. Erzeug dir mal ein FileStream, öffne eine Datei, schreib was rein und ruf kein Close/Dispose auf. Nach beendigung des Programms wird weder Dispose noch Close aufgerufen und in der Datei steht nichts drinne.Warum auch sollte sich die Runtime darum kümmern das aufzuräumen was der Entwickler nicht beachtet hat.
Dispose wird automatisch aufgerufen. Siehe unten. Der Entwickler hat mit dem IDisposeable-Pattern lediglich die zusätzliche Möglichkeit den Zeitpunkt des Dispose selbst zu bestimmern wenn das notwendig ist.
http://msdn.microsoft.com/de-de/library/fs2xkftw(v=VS.80).aspx
Zitat:
"Die Basisklasse stellt eine Finalize-Methode bzw. einen Destruktor als Sicherheit für den Fall bereit, dass Dispose nicht aufgerufen wird. Die Finalize-Methode ruft die Dispose-Methode auf, die Parameter akzeptiert, und übergibt dabei false.
http://msdn.microsoft.com/de-de/library/b1yfkh5e(v=VS.80).aspx
Zitat:
"Beachten Sie, dass Sie auch bei Bereitstellung einer expliziten Steuerung mithilfe von Dispose eine implizite Bereinigung mithilfe der Finalize-Methode bereitstellen müssen. Finalize bietet eine Sicherung, um permanente Ressourcenverluste zu verhindern, falls der Programmierer Dispose nicht aufruft."
-
Ist nur komisch das das bei allen Implementierungen die ich kenne, wie FileStream,StreamWriter, SharePoint Klassen NIE zur Sicherheit aufgerufen wird und man Probleme bekommt wenn man es nicht macht.
-
Firefighter schrieb:
Ist nur komisch das das bei allen Implementierungen die ich kenne, wie FileStream,StreamWriter, SharePoint Klassen NIE zur Sicherheit aufgerufen wird und man Probleme bekommt wenn man es nicht macht.
Man bekommt Probleme, weil Dispose() zu spät aufgerufen wird und so z.B. keine freien Handles mehr verfügbar sind.
Dispose() wird aufgerufen, entweder direkt oder via Finalizer.
Voraussetzung ist natürlich ein korrekt implementierter Finalizer.Simon
-
@ Loks, also deine Zitate finde ich auf keinen der beiden Seiten!?
-
Firefighter schrieb:
@ Loks, also deine Zitate finde ich auf keinen der beiden Seiten!?
Du darfst den Link nicht clicken, sondern musst ihn in deine Adresszeile kopieren und manuell aufrufen, da die Forensoftware Probleme mit ( und ) in Links hat, und diese daher nicht korrekt verlinkt.
-
Das habe ich auch gemacht und auf den Seiten finde ich den Zitierten Text ebenfalls nicht.
//Edit, ah nun doch, hatte vorhin scheinbar falsch gesucht
-
@loks:
Also wenn man keine Ahnung hat...Dispose wird nie automatisch aufgerufen. Nur der Finalizer wird automatisch aufgerufen. Der Finalizer und Dispose sind zwar nicht ganz unverwandt, aber auch lange nicht dasselbe.
Und ja, es gibt viele Objekte die nie finalisiert/collected werden wenn man sie nicht Disposed. Üblicherweise gehören da Timer dazu, die rooten sich meist selbst, und entfernen diese GC-Root erst wieder, wenn man sie disposed.
BTW: die Geschichte dass der Finalizer Dispose(false) aufruft nennt man das "Dispose Pattern". Ist ein riesen dummer Patzer von MS, ich kenne keinen der das verwendet. Weil es sinnlos ist. Weil es voraussetzt dass man innerhalb einer Klasse andere IDisposable Member hat UND eigene unmanages Resourcen die man "direkt" selbst kontrolliert. Was schonmal ganz mieses Design ist. Der Finalizer tut das im Übrigen auch nicht selbst, man muss den schon selbst so implementieren dass er es tut. Oder von einer Klasse ableiten deren Finalizer schon passend implementiert ist.
