Die App, die ich schreibe, leidet ziemlich dramatisch unter einem Speicherverlust. So gut wie das gesamte Objektmodell bleibt im Speicher, wenn ein Benutzer ein geladenes Projekt schließt. Ich weiß das, weil das Schließen eines Projekts in meiner App kaum Auswirkungen auf die Speichernutzung im Task-Manager hat und das Öffnen eines neuen Projekts es fast jedes Mal verdoppelt. Ich habe jetBrain dotTrace Memory 3.5 heruntergeladen, aber es gibt wenig (keine) Anweisungen zur Verwendung. Ich habe irgendwie herausgefunden, wie man es benutzt und es zeigt, dass das gesamte Objektmodell immer noch im Speicher ist, wenn ich einen Schnappschuss mache, nachdem ein Projekt beendet wurde. Wenn ich meinen Projektcode durchforste, sehe ich keinen Grund dafür. Kennt jemand irgendetwas, das normalerweise zu Speicherlecks in C # oder zu Tools oder Techniken zum Aufspüren des Problems führt? Es ist alles gut und gut, eine App zu haben, die zeigt, dass mein gesamtes Objektmodell immer noch in den Speicher geladen ist, aber es zeigt mir nicht, welches Objekt oder welche Variable es speichert. Vielen Dank im Voraus.
Untersuchen Sie zunächst, ob das Leck auf die Registrierung von Ereignishandlern zurückzuführen sein könnte, da dies eine der einfachsten Möglichkeiten ist, Ihre Objekte versehentlich zu rooten. Wenn Sie zum Beispiel eine Klasse 'Bob' haben, die eine ihrer Methoden 'OnSomeEvent' als Delegat zu einem Ereignis hinzufügt, das von einer langlebigen Komponente Ihres Systems ausgelöst wird (zB 'UserSettingsManager'), dann Objekte der Klasse 'Bob' 'werden nicht gesammelt, da sie als Event-Handler am Leben erhalten werden (dh Event-Callbacks sind keine schwachen Referenzen).
Als Alternative zu den kommerziellen Tools gibt es eine Erweiterung des Windows-Debuggers namens SoS (Son of Strike), mit der Sie verwaltete Anwendungen debuggen können. Es ist jedoch nicht die Zartbesaiteten, da es ein Low-Level-Befehlszeilen-Tool ist, das viel Vor-Lernen erfordert. Es ist jedoch sehr leistungsfähig und hat nicht so viel mit größeren Prozessen (im Hinblick auf den Haufenverbrauch) zu kämpfen wie die kommerziellen Tools.
Was die kommerziellen Profiler betrifft, habe ich gute Erfahrungen mit Redgate's ANTS Memory Profiler gemacht (aber ich hatte Kollegen, die es hassen), also könnte es sich lohnen, das auszuprobieren.
Wahrscheinlich ist die häufigste Ursache für verwaltete Speicherlecks nicht abgemeldete Ereignishandler.
Es gibt eine Reihe von nützlichen Tools, um solche Fehler zu verfolgen. Persönlich mag ich ANTS Memory Profiler und WinDbg / SOS. Sie möchten herausfinden, was die Objektgraphen roofiert. Mit WinDbg / SOS gibt es einen !gcroot -Befehl, der Ihnen die Wurzeln eines gegebenen Objekts verrät.
In Tess-Blog finden Sie Anleitungen zur Behebung von Speicherproblemen mithilfe von WinDbg / SOS.
Tags und Links memory-leaks .net c#