C # .NET Garbage Collection funktioniert nicht?

  

Nach erfolgloser Suche nach Lecks

Versuchen Sie es härter =)

Speicherlecks in einer verwalteten Sprache können schwierig zu finden sein. Ich habe gute Erfahrungen mit dem Redgate ANTS Memory Profiler gemacht. Es ist nicht kostenlos, aber Sie erhalten eine 14-tägige Testversion mit vollem Funktionsumfang. Es hat eine nette Benutzeroberfläche und zeigt Ihnen, wo Sie Speicher zugewiesen ist und warum diese Objekte im Speicher gehalten werden.

Wie Alex sagt, sind Ereignishandler eine sehr häufige Quelle für Speicherlecks in einer .NET-App. Bedenken Sie Folgendes:

Ich habe eine statische Klasse verwendet, um das Problem so offensichtlich wie möglich zu machen. Nehmen wir an, dass während der Lebensdauer Ihrer Anwendung viele Foo -Objekte erstellt werden. Jedes Foo abonniert das Ereignis SomeEvent der statischen Klasse.

Die Foo -Objekte können zu einem bestimmten Zeitpunkt aus dem Gültigkeitsbereich fallen, aber die statische Klasse behält über den Event-Handler-Delegaten einen Verweis auf jeden einzelnen. Somit werden sie auf unbestimmte Zeit am Leben erhalten. In diesem Fall muss der Event-Handler einfach "abgehakt" werden.

  

... das XNA-Projekt schien eine Menge Byte-Arrays gespeichert zu haben, die ich tatsächlich verwendete ...

Sie könnten in der LOH in Fragmentierung geraten. Wenn Sie große Objekte sehr häufig zuweisen, können sie das Problem verursachen. Die Gesamtgröße dieser Objekte ist möglicherweise viel kleiner als der gesamte der Laufzeit zugewiesene Speicher. Aufgrund der Fragmentierung wird Ihrer Anwendung jedoch viel ungenutzter Speicher zugewiesen.

Der Profiler, mit dem ich oben verlinkt bin, wird Ihnen sagen, ob das ein Problem ist. Wenn dies der Fall ist, können Sie es wahrscheinlich irgendwo zu einem Objektleck zurückverfolgen. Ich habe gerade ein Problem in meiner App behoben, das das gleiche Verhalten zeigt, und es war daran zu denken, dass MemoryStream seine interne byte[] nicht freigegeben hat, obwohl sie Dispose() aufgerufen hat. Das Wrapping des Streams in einem Dummy-Stream und das Auflösen des Streams beseitigten das Problem.

Stellen Sie unter Angabe des Offensichtlichen auch sicher, dass Dispose() Ihrer Objekte IDisposable implementiert. Es kann natürliche Ressourcen geben, die herumliegen. Auch hier wird ein guter Profiler das fangen.

Mein Vorschlag; Es ist nicht der GC, das Problem liegt in Ihrer App. Verwenden Sie einen Profiler, bringen Sie Ihre App in einen hohen Speicherverbrauch, erstellen Sie einen Speicher-Snapshot und beginnen Sie mit der Analyse.

In erster Linie funktioniert der GC und funktioniert gut. Es gibt keinen Fehler darin, den Sie gerade entdeckt haben.

Nun, da wir das aus dem Weg geschafft haben, ein paar Gedanken:

1. Verwenden Sie zu viele Threads?
2. Denken Sie daran, dass GC nicht deterministisch ist; es wird ausgeführt, wenn es denkt, dass es ausgeführt werden muss (selbst wenn Sie GC.Collect() aufrufen.
3. Sind Sie sicher, dass all Ihre Referenzen nicht mehr in den Geltungsbereich fallen?
4. Was laden Sie überhaupt in den Speicher? Große Bilder? Große Textdateien?

Ihr Profiler sollte Ihnen sagen, was so viel Speicher verbraucht. Fangen Sie an, die größten Übeltäter so oft wie möglich zu schneiden.

Auch das Aufrufen von GC.Collect () alle X Sekunden ist eine schlechte Idee und wird Ihr wahres Problem wahrscheinlich nicht lösen.

Bearbeiten: Link zur Fragmentierung von großen Objekthaufen hinzugefügt.

Bearbeiten: Da es so aussieht, als ob es ein Problem beim Zuweisen und Wegwerfen der Texturen ist, können Sie Texture2D.SetData verwenden, um das große Byte [] s wiederzuverwenden?

Zunächst müssen Sie herausfinden, ob es sich um verwalteten oder nicht verwalteten Speicher handelt, der undicht ist.

1. Verwenden Sie perfmon, um zu sehen, was mit Ihrem Prozess passiert. '.net memory # Bytes in allen Heaps' und Process\Private Bytes . Vergleichen Sie die Zahlen und der Speicher steigt. Wenn der Anstieg von privaten Bytes den Anstieg des Heap-Speichers übersteigt, ist das Wachstum des nicht verwalteten Speichers groß.

2. Nicht verwaltetes Speicherwachstum würde auf Objekte zeigen, die nicht entsorgt werden (aber schließlich gesammelt werden, wenn ihr Finalizer ausgeführt wird).

3. Wenn das Speicherwachstum verwaltet wird, müssen wir sehen, welche Generation / LOH (es gibt auch Leistungsindikatoren für jede Generation von Heap-Bytes).

4. Wenn es sich um Large Object Heap-Bytes handelt, sollten Sie die Verwendung und das Wegwerfen von Large-Byte-Arrays überdenken. Vielleicht können die Byte-Arrays wiederverwendet werden anstatt verworfen zu werden. Ziehen Sie auch die Zuweisung von großen Byte-Arrays mit Potenzen von 2 in Betracht. Auf diese Weise hinterlassen Sie bei der Anordnung ein großes "Loch" im großen Objekt-Heap, das von einem anderen Objekt der gleichen Größe ausgefüllt werden kann.

5. Ein letztes Anliegen ist die Erinnerung, aber ich habe keinen Rat für Sie, weil ich es nie durcheinander gebracht habe.

Ich würde auch hinzufügen, dass, wenn Sie einen Dateizugriff machen, stellen Sie sicher, dass Sie alle Leser oder Autoren schließen und / oder entsorgen. Sie sollten eine übereinstimmende 1-1 zwischen dem Öffnen einer Datei und dem Schließen haben.

Auch verwende ich normalerweise die using-Klausel für Ressourcen, wie eine SQL-Verbindung:

Implementieren Sie IDisposable für beliebige Objekte und möglicherweise etwas Brauchbares, das Probleme verursacht? Ich würde alle IDisposable Codes überprüfen.