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 die im verwalteten Speicher zugewiesenen Objekte und fordert sie zurück. Periodisch führt der Garbage Collector eine Garbage Collection durch, um Speicher zurückzugewinnen, der Objekten zugewiesen wurde, für die es keine gültigen Referenzen gibt. 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 mit der Methode Collect 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, die nicht referenziert werden, zu beenden.
3. Der Garbage Collector gibt Objekte frei, die nicht referenziert sind, und fordert ihren Speicher zurück.

Nicht verwaltete Ressourcen

Während einer Sammlung 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.

Abgesehen von verwalteten Speicherzuweisungen verwalten Implementierungen des Garbage Collector keine Informationen zu Ressourcen, 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; jedoch implementieren in C# oder C++ geschriebene Typen Destruktoren, die von Compilern in ein Überschreiben von Object.Finalize umgewandelt werden. Wenn ein Objekt über einen Finalizer verfügt, ruft der Garbage Collector diesen in den meisten Fällen auf, bevor er das Objekt freigibt. Der Garbage Collector ist jedoch nicht immer verpflichtet, Finalizer in allen Situationen aufzurufen; die SuppressFinalize Methode verhindert beispielsweise explizit, dass der Finalizer eines Objekts aufgerufen wird. Der Garbage Collector ist auch nicht verpflichtet, einen bestimmten Thread für die Finalisierung von Objekten zu verwenden oder die Reihenfolge zu garantieren, in der Finalizer für Objekte aufgerufen werden, die sich gegenseitig referenzieren, aber ansonsten für die Garbage Collection zur Verfügung stehen.

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 Ressourcenverwaltungs- und Bereinigungsaufgaben ausgeführt werden. Klassen, die Dispose implementieren, müssen als Teil ihres Klassenvertrags angeben, ob und wann Nutzer der Klasse die Methode aufrufen, um das Objekt aufzuräumen. Der Garbage Collector ruft die Methode Dispose standardmäßig nicht auf; Implementierungen der Dispose Methode können jedoch Methoden in der GC Klasse aufrufen, um das Finalisierungsverhalten des Garbage Collectors anzupassen.

Weitere Informationen über die Finalisierung von Objekten und das Dispose-Muster finden Sie unter Aufräumen von nicht verwalteten 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, bieten Ihnen die Möglichkeit, die älteste Generation anzugeben, die garbage collected werden soll.

Garbage Collection nicht zulassen

Der Garbage Collector unterstützt einen Latenzmodus ohne GC Region, der während der Ausführung von kritischen Pfaden verwendet werden kann, in denen die Garbage Collection die Leistung einer App beeinträchtigen kann. Der Latenzmodus no GC region erfordert, dass Sie eine Menge an Speicher angeben, die ohne Beeinträchtigung durch den Garbage Collector zugewiesen 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 Beginn des kritischen Pfades der no GC Region, indem Sie eine der Überladungen der Methode TryStartNoGCRegion aufrufen. Sie geben das Ende des kritischen Pfads an, indem Sie die EndNoGCRegion Methode aufrufen.

Sie können Aufrufe der TryStartNoGCRegion-Methode nicht verschachteln und sollten die EndNoGCRegion-Methode nur aufrufen, wenn sich die Laufzeit aktuell im Latenzmodus der no 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 .