Also, nach der Entdeckung Die Bitmap-Klasse erwartet, dass der ursprüngliche Stream für die Lebensdauer des Bildes oder der Bitmap geöffnet bleibt. Ich habe mich entschieden, herauszufinden, ob die Bitmap-Klasse den Stream tatsächlich schließt, wenn er entsorgt wird.
Beim Betrachten des Quellcodes erstellen die Bitmap- und Image-Klassen eine GPStream-Instanz, um den Stream zu umbrechen, aber speichert keinen Verweis auf die GPStream- oder Stream-Instanz .
%Vor%Nun implementiert die GPStream-Klasse (intern) keine Release- oder Dispose-Methode - nichts, was GDI erlauben würde, den Stream zu schließen oder zu verwerfen. Da die Image / Bitmap-Klasse keinen Verweis auf die GPStream-Instanz enthält, scheint es zu sein, dass GDI, Drawing.Bitmap oder Drawing.Stream absolut nicht möglich sind, den Stream ordnungsgemäß zu schließen .
Ich könnte Bitmap ableiten, um das zu beheben, aber, warte, es ist versiegelt .
Bitte sagen Sie mir, dass ich falsch liege und dass MS es nicht einfach unmöglich gemacht hat, Code zu schreiben, der keine Ressourcen mit seiner API verliert.
Da Sie in diesem Beispiel den Stream angeben, würde ich mir vorstellen, dass Sie dafür verantwortlich sind.
Es ist eine gute Übung, die Methode, die einen Stream öffnet, auch zu schließen. Auf diese Weise ist es einfacher, Lecks im Auge zu behalten. Es wäre ziemlich seltsam, ein anderes Objekt zu haben, das den Stream schließt, den du geöffnet hast.
Da die Bitmap nicht garantieren kann, in welcher Reihenfolge der Destruktor aufgerufen wird, wird der Stream nicht geschlossen, da er möglicherweise bereits während der Garbage Collection mit einem eigenen Destruktor geschlossen wurde. Jeffrey Richters CLR über C # hat ein Kapitel über Speicherverwaltung, das viel klarer erklärt, als ich kann.
Tags und Links memory-leaks .net c# gdi+ system.drawing