System.GC-Klasse

Dieser Artikel enthält ergänzende Hinweise zur Referenzdokumentation für diese API.

Die GC Klasse steuert den Garbage Collector. Der Garbage Collector ist eine Common Language Runtime-Komponente, die die Zuordnung und Freigabe des verwalteten Speichers steuert. Die Methoden in dieser Klasse beeinflussen, wann die Garbage Collection für ein Objekt ausgeführt wird und wann Ressourcen freigegeben werden, die einem Objekt zugeordnet sind. Eigenschaften in dieser Klasse enthalten Informationen über die Gesamtmenge des verfügbaren Arbeitsspeichers im System und der Alterskategorie oder Generierung des Speichers, der einem Objekt zugeordnet ist.

Der Garbage Collector verfolgt und gibt Objekte zurück, die im verwalteten Speicher zugeordnet sind. In regelmäßigen Abständen führt der Garbage Collector die Garbage Collection aus, um Speicher freizugeben, der Objekten zugeordnet ist, für die keine gültigen Verweise vorhanden sind. Die Garbage Collection erfolgt automatisch, wenn eine Speicheranforderung nicht mit verfügbarem freien Arbeitsspeicher erfüllt werden kann. Alternativ kann eine Anwendung die Garbage Collection mithilfe der Collect Methode erzwingen.

Die Garbage Collection besteht aus den folgenden Schritten:

1. Der Garbage Collector sucht nach verwalteten Objekten, auf die in verwaltetem Code verwiesen wird.
2. Der Garbage Collector versucht, Objekte abzuschließen, auf die nicht verwiesen wird.
3. Der Garbage Collector gibt Objekte frei, auf die nicht verwiesen wird, und gibt ihren Speicher frei.

Nicht verwaltete Ressourcen

Während einer Auflistung gibt der Garbage Collector kein Objekt frei, wenn ein oder mehrere Verweise auf das Objekt im verwalteten Code gefunden werden. Der Garbage Collector erkennt jedoch keine Verweise auf ein Objekt aus nicht verwalteten Code und kann Objekte freigeben, die ausschließlich im nicht verwalteten Code verwendet werden, sofern dies nicht explizit verhindert wird. Die KeepAlive Methode stellt einen Mechanismus bereit, der verhindert, dass der Garbage Collector Objekte sammelt, die noch in nicht verwaltetem Code verwendet werden.

Neben verwalteten Speicherzuweisungen Standard Implementierungen des Garbage Collectors keine Informationen zu Ressourcen enthalten, die von einem Objekt gespeichert werden, z. B. Dateihandles oder Datenbankverbindungen. Wenn ein Typ nicht verwaltete Ressourcen verwendet, die freigegeben werden müssen, bevor Instanzen des Typs erneut beansprucht werden, kann der Typ einen Finalizer implementieren.

In den meisten Fällen werden Finalizer durch Überschreiben der Object.Finalize Methode implementiert. In C# oder C++ geschriebene Typen implementieren jedoch Destruktoren, die Compiler in eine Außerkraftsetzung umwandeln Object.Finalize. Wenn ein Objekt einen Finalizer aufweist, ruft der Garbage Collector es in den meisten Fällen auf, bevor das Objekt freigegeben wird. Der Garbage Collector ist jedoch nicht erforderlich, finalizer in allen Situationen aufzurufen; Die Methode verhindert beispielsweise explizit, dass der SuppressFinalize Finalizer eines Objekts aufgerufen wird. Außerdem ist der Garbage Collector nicht erforderlich, um Objekte mit einem bestimmten Thread abzuschließen, oder garantiert die Reihenfolge, in der Finalizer für Objekte aufgerufen werden, die einander referenzieren, aber andernfalls für die Garbage Collection verfügbar sind.

In Szenarien, in denen Ressourcen zu einem bestimmten Zeitpunkt freigegeben werden müssen, können Klassen die IDisposable Schnittstelle implementieren, die die Methode enthält, mit der IDisposable.Dispose Ressourcenverwaltung und sauber Up-Vorgänge ausgeführt werden. Klassen, die implementiert Dispose werden, müssen als Teil ihres Klassenvertrags angeben, ob und wann Klassenkunden die Methode aufrufen, um das Objekt zu sauber. Der Garbage Collector ruft die Methode standardmäßig nicht auf Dispose . Implementierungen der Methode können jedoch Methoden in der DisposeGC Klasse aufrufen, um das Endisierungsverhalten des Garbage Collector anzupassen.

Weitere Informationen zur Objektdefinierung und zum Dispose-Muster finden Sie unter Bereinigen nicht verwalteter Ressourcen.

Alterung von Objekten und Generationen

Der Garbage Collector in der Common Language Runtime unterstützt das Altern von Objekten mithilfe von Generationen. Eine Generation ist eine Maßeinheit des relativen Alters von Objekten im Arbeitsspeicher. Die Generationsnummer oder das Alter eines Objekts gibt die Generierung an, zu der ein Objekt gehört. Objekte, die kürzlich erstellt wurden, sind Teil neuerer Generationen und weisen niedrigere Generationennummern auf als Objekte, die zuvor im Lebenszyklus der Anwendung erstellt wurden. Objekte in der letzten Generation befinden sich in der Generation 0. Diese Implementierung des Garbage Collector unterstützt drei Generationen von Objekten, Generationen 0, 1 und 2. Sie können den Wert der MaxGeneration Eigenschaft abrufen, um die vom System unterstützte maximale Generationsnummer zu ermitteln.

Das Altern von Objekten ermöglicht Es Anwendungen, die Garbage Collection auf eine bestimmte Gruppe von Generationen zu richten, anstatt dass der Garbage Collector alle Generationen auswerten muss. Überladungen der Collect Methode, die einen generation Parameter enthalten, ermöglichen es Ihnen, die älteste Generation anzugeben, die garbage collection werden soll.

Aufheben der Verwendung der Garbage Collection

Der Garbage Collector unterstützt keinen GC-Regionslatenzmodus, der bei der Ausführung kritischer Pfade verwendet werden kann, bei denen die Garbage Collection die Leistung einer App beeinträchtigen kann. Der Latenzmodus für die GC-Region erfordert, dass Sie einen Arbeitsspeicher angeben, der ohne Störungen des Garbage Collector zugeordnet werden kann. Wenn die Laufzeit diesen Speicher zuordnen kann, führt die Laufzeit keine Garbage Collection durch, während Code im kritischen Pfad ausgeführt wird.

Sie definieren den Anfang des kritischen Pfads der no GC-Region, indem Sie eine der Überladungen der TryStartNoGCRegion. Sie geben das Ende des kritischen Pfads an, indem Sie die EndNoGCRegion Methode aufrufen.

Aufrufe der TryStartNoGCRegion Methode können nicht geschachtelt werden, und Sie sollten die EndNoGCRegion Methode nur aufrufen, wenn sich die Laufzeit derzeit nicht im Latenzmodus der GC-Region befindet. Mit anderen Worten, Sie sollten nicht mehrmals aufrufen TryStartNoGCRegion (nach dem ersten Methodenaufruf werden nachfolgende Aufrufe nicht erfolgreich ausgeführt), und Sie sollten nicht erwarten, dass Aufrufe EndNoGCRegion erfolgreich ausgeführt werden, nur weil der erste Aufruf erfolgreich war TryStartNoGCRegion .