Ich versuche, die Speichernutzung einer winForm-Anwendung zu reduzieren.
In der Anwendung gibt es ein Hauptformular und ein Einstellungsformular. Wenn die Schaltfläche "Einstellung" gedrückt wurde, wird das Einstellungsformular als modales Formular angezeigt. Das Einstellungsformular lädt die app.config-Daten aus der Konfigurationsdatei und liest sie als Hashtable in den Speicher. Nachdem das Einstellungsformular geschlossen wurde, wird die Dispose-Methode von Windows.Forms.Form aufgerufen. Die Dispose-Methode ist so einfach wie das Hashtables-Objekt und das app.config-Objekt auf null setzen.
SettingForm als Modalform anzeigen:
%Vor%Dispose-Methode:
%Vor%Hinweis: mySetting ist eine Instanz von Class, bei der alle app.config-Daten in Hashtable geladen wurden, und testFtp ist ein benutzerdefiniertes Objekt für die ftp-Funktion. Sollte ich die Dispose-Methode für diese zwei Klassen implementieren und
verwenden? %Vor%statt sie auf null zu setzen, da sie selbst mit nicht verwalteten Ressourcen umgehen?
Aber jedes Mal, wenn Sie die Schaltfläche "Einstellung" drücken und das Einstellungsformular schließen, wird das private Byte für einige hundert K erhöht. Speicherleck? Wie könnte ich es loswerden?
Wie Sie am Ende Ihrer Frage vorgeschlagen haben, würde ich IDisposable für mySetting und testFtp empfehlen. Sie sollten eine bessere Bereinigung der Ressourcen sehen, wenn Sie Folgendes implementiert haben:
Kleine Bearbeitung:
Basierend auf Nayans Antwort und der Antwort, auf die er verweist: Ich würde die Implementierung von IDisposable wärmstens empfehlen. Wenn Sie Forms verwenden und von den Scripts der Klasse Forms abgeleitet sind, überprüfen Sie, ob IDisposable implementiert werden muss. Dies bedeutet nicht, dass Ihr Code es implementieren sollte, nur dass Sie wirklich überprüfen sollten, um sicherzustellen, dass Sie es nicht brauchen. Für Formulare werden normalerweise viele Ereignisse veröffentlicht und abonniert. Formulare sind auch berüchtigt dafür, ein Catch-All-Ressource Eimer, IMO.
Der Speicher wird möglicherweise aufgrund eines anderen Codes nicht freigegeben. Da du nicht viele Details angegeben hast, gehe ich jetzt davon aus, dass alles andere optimal ist.
Die Objekte, mit denen Sie arbeiten, werden vom Garbage Collector (wie Sie es kennen) gesammelt. Aber sie werden möglicherweise nicht aus der Erinnerung entlassen, wenn Sie es wollen. .NET-Objekte werden besser dem Garbage Collector überlassen.
Je nachdem, warum der Speicher möglicherweise nicht freigegeben wird, haben Sie die Antworten hier.
Das Festlegen des Objektverweises auf null macht keinen großen Unterschied. Andererseits habe ich persönlich einige Male aufgenommen, Objekte, die lebendig zurückkommen (und an alte Generationen weitergegeben werden), weil Sie sie verwenden, während Sie null auf dasselbe setzen. Es ist eine andere Form der Interferenz mit GC, aber Ihre Wahl.
Sie müssen möglicherweise IDisposable nicht implementieren, aber wenn Sie mit Streams, Betriebssystem-Handles und nicht verwalteten Ressourcen arbeiten, sollten Sie das tun.
Bearbeiten:
Die Speicherbelegung ist möglicherweise hoch, aber es liegt in der Verantwortung des GC, sie freizugeben, solange Sie die Referenzen nicht am Leben erhalten. Also, wenn Sie alle Vorsichtsmaßnahmen getroffen haben, scheint es immer noch, dass Ihre Anwendung viel Speicher verbraucht. Das ist akzeptabel, da das Freigeben der nicht referenzierten Objekte der Verantwortung des Garbage Collectors unterliegt.
Warum denken Sie, dass es ein Leck ist? GC ist nicht verpflichtet, Speicher sofort freizugeben, unter gewissen Umständen kann er die Sammlung nie wirklich durchführen und das wäre in Ordnung.
Wenn Sie diese sofort freigegebenen Kilobyte wirklich benötigen, können Sie GC erzwingen, die Bereinigung unmittelbar nach den Veräußerungen durchzuführen, aber dies ist im Allgemeinen ein kostspieliger Vorgang und kann sich auf die Gesamtleistung auswirken.
Tags und Links c# memory-management