In Bezug auf meine vorherige Frage , Ich muss überprüfen, ob eine Komponente, die von Castle Windsor instanziiert werden soll, nach dem Code-Code, der sie verwendet hat, Müll gesammelt werden kann. Ich habe den Vorschlag in den Antworten von der vorherigen Frage versucht, aber es scheint nicht zu funktionieren, zumindest für meinen Code. Daher möchte ich einen Komponententest schreiben, der testet, ob eine bestimmte Objektinstanz nach der Ausführung eines Teils meines Codes als Garbage Collected erfasst werden kann.
Kann man das auf zuverlässige Weise tun?
BEARBEITEN
Ich habe derzeit den folgenden Test basierend auf der Antwort von Paul Stovell, die erfolgreich ist:
%Vor%Habe ich richtig angenommen, dass basierend auf dem obigen Test, kann ich folgern, dass Windsor Speicher bei der Verwendung der NoTrackingReleasePolicy nicht verlieren wird?
Das mache ich normalerweise:
%Vor%Hinweis: Es gibt sehr wenige Zeiten, in denen Sie GC.Collect () in einer Produktionsanwendung aufrufen sollten. Aber das Testen auf Lecks ist ein Beispiel dafür, wo es angebracht ist.
Vielleicht könntest du eine WeakReference dafür halten und dann nachsehen, ob es funktioniert nicht mehr am Leben (dh! IsAlive), nachdem die Tests abgeschlossen sind.
Basierend auf auf Pauls Antwort erstellte ich eine wiederverwendbare Assert-Methode. Da string nach Wert kopiert werden, habe ich eine explizite Überprüfung für sie hinzugefügt. Sie können vom Müllsammler gesammelt werden.
Die folgenden Komponententests zeigen, dass die Funktion in einigen gängigen Szenarien funktioniert.
%Vor% Aufgrund von Unterschieden bei der Verwendung der Release -Konfiguration (ich nehme Compiler-Optimierungen an), würden einige dieser Komponententests fehlschlagen, wenn GC.KeepAlive() nicht aufgerufen werden sollte.
Kompletter Quellcode (einschließlich einiger der verwendeten Hilfsmethoden) kann in meiner Bibliothek gefunden werden .
Dies ist keine Antwort. Sie können jedoch versuchen, Ihren Code sowohl in den Modi Debug als auch Release auszuführen (zum Vergleich).
Nach meiner Erfahrung ist die Debug Version von JIT'ed Code einfacher zu debuggen und kann daher Referenzen länger am Leben erhalten (ich glaube Funktionsumfang) Allerdings JIT-Code in Release Im Modus können die Objekte schnell zur Sammlung bereit sein, sobald sie nicht mehr verfügbar sind und eine Sammlung stattfindet.
Beantworten Sie auch Ihre Frage nicht: :-)
Ich wäre daran interessiert zu sehen, Sie diesen Code mit Visual Studio im Interop-Modus (Managed und Native) zu debuggen und dann nach dem Anzeigen eines Meldungsfelds oder etwas. Dann können Sie den Debug- & gt; Windows-Immediate öffnen und dann
(oder Sie können Windbg verwenden, wie andere in früheren Posts gepostet haben)
Danke, Aaron
Tags und Links .net c# unit-testing garbage-collection