System.GC-klasse

Opmerking

In dit artikel vindt u aanvullende opmerkingen in de referentiedocumentatie voor deze API.

De GC klasse bepaalt de garbagecollector. De garbagecollector is een algemeen taalruntime-onderdeel dat de toewijzing en release van beheerd geheugen beheert. De methoden in deze klasse beïnvloeden wanneer vuilnisverzameling wordt uitgevoerd op een object en wanneer de door een object toegewezen hulpbronnen worden vrijgegeven. Eigenschappen in deze klasse bevatten informatie over de totale hoeveelheid geheugen die beschikbaar is in het systeem en de leeftijdscategorie of generatie van geheugen die aan een object is toegewezen.

De garbagecollector houdt objecten bij die zijn toegewezen in beheerd geheugen en maakt ze vrij. Periodiek voert de vuilnisophaler geheugenbeheer uit om geheugen terug te winnen dat is toegewezen aan objecten waarvoor geen geldige verwijzingen meer bestaan. Geheugenopruiming wordt automatisch uitgevoerd wanneer een geheugenaanvraag niet kan worden voorzien met het beschikbare geheugen. Een toepassing kan ook garbagecollection afdwingen met behulp van de Collect methode.

Garbagecollection bestaat uit de volgende stappen:

1. De garbagecollector zoekt naar beheerde objecten waarnaar wordt verwezen in beheerde code.
2. De garbagecollector probeert objecten te voltooien waarnaar niet wordt verwezen.
3. De vuilnisverzamelaar verwijdert objecten die niet meer worden gebruikt en herwint hun geheugen.

Onbeheerde resources

Tijdens een verzameling maakt de garbagecollection een object niet vrij als er een of meer verwijzingen naar het object in beheerde code worden gevonden. De garbagecollector herkent echter geen verwijzingen naar een object uit onbeheerde code en kan objecten vrij maken die uitsluitend in onbeheerde code worden gebruikt, tenzij dit expliciet wordt voorkomen. De KeepAlive methode biedt een mechanisme waarmee wordt voorkomen dat de garbagecollector objecten verzamelt die nog steeds in gebruik zijn in onbeheerde code.

Afgezien van beheerde geheugentoewijzingen onderhouden implementaties van de garbagecollector geen informatie over resources die door een object worden bewaard, zoals bestandsingangen of databaseverbindingen. Wanneer een type niet-beheerde resources gebruikt die moeten worden vrijgegeven voordat exemplaren van het type worden opgehaald, kan het type een finalizer implementeren.

In de meeste gevallen worden finalizers geïmplementeerd door de Object.Finalize-methode te overschrijven; echter, typen die zijn geschreven in C# of C++ implementeren destructors, die compilers omzetten in een overschrijving van Object.Finalize. In de meeste gevallen, als een object een finalizer heeft, roept de garbagecollector het aan voordat het object wordt vrijgemaakt. De garbage collector is echter niet verplicht om finalizers in alle situaties aan te roepen; de SuppressFinalize-methode voorkomt bijvoorbeeld expliciet dat de finalizer van een object wordt aangeroepen. Bovendien is het voor de garbagecollector niet verplicht om een specifieke thread te gebruiken om objecten af te handelen, of om de volgorde te garanderen waarin finalizers worden aangeroepen voor objecten die naar elkaar verwijzen, maar die anders beschikbaar zijn voor garbage collection.

In scenario's waarin resources op een bepaald tijdstip moeten worden vrijgegeven, kunnen klassen de IDisposable interface implementeren, die de IDisposable.Dispose methode bevat waarmee resourcebeheer- en opschoontaken worden uitgevoerd. Klassen die Dispose implementeren, moeten als onderdeel van hun klassecontract opgeven of en wanneer gebruikers van de klasse de methode aanroepen om het object op te ruimen. De garbagecollector roept standaard de Dispose methode niet aan. Implementaties van de Dispose methode kunnen echter methoden in de GC klasse aanroepen om het uiteindelijke gedrag van de garbagecollector aan te passen.

Zie Opschonen van niet-beheerde resources voor meer informatie over het voltooien van objecten en het verwijderingspatroon.

Objectveroudering en generaties

De garbagecollector in de algemene taalruntime ondersteunt objectveroudering met behulp van generaties. Een generatie is een maateenheid van de relatieve leeftijd van objecten in het geheugen. Het generatienummer of de leeftijd van een object geeft de generatie aan waartoe een object behoort. Objecten die onlangs zijn gemaakt, maken deel uit van nieuwere generaties en hebben lagere generatienummers dan objecten die eerder in de levenscyclus van de toepassing zijn gemaakt. Objecten in de meest recente generatie zijn in generatie 0. Deze implementatie van de vuilnisophaling ondersteunt drie generaties objecten, generaties 0, 1 en 2. U kunt de waarde van de MaxGeneration eigenschap ophalen om het maximale generatienummer te bepalen dat door het systeem wordt ondersteund.

Met objectveroudering kunnen toepassingen zich richten op vuilnisophaling voor een specifieke set generaties in plaats van dat de vuilnisophaler alle generaties moet evalueren. Overbelastingen van de Collect-methode met een generation-parameter stellen u in staat om de oudste generatie te specificeren voor garbage collection.

Garbage collection uitschakelen

De geheugenbeheerder ondersteunt een geen-GC-regio latentiemodus die kan worden gebruikt tijdens de uitvoering van kritieke trajecten waarin het verzamelen van afval de prestaties van een app nadelig kan beïnvloeden. Voor de geen GC-regio latentiemodus moet u een hoeveelheid geheugen opgeven die zonder interferentie van de garbagecollector kan worden toegewezen. Als de runtime dat geheugen kan toewijzen, voert de runtime geen garbage-collection uit terwijl de code in het kritieke pad wordt uitgevoerd.

U definieert het begin van het kritieke pad van de geen GC-regio door een van de overbelastingen van de TryStartNoGCRegion. U geeft het einde van het kritieke pad op door de EndNoGCRegion methode aan te roepen.

U kunt geen aanroepen naar de TryStartNoGCRegion methode nesten en u mag de EndNoGCRegion methode alleen aanroepen als de runtime zich momenteel in de modus met geen GC-regio latentie bevindt. Met andere woorden, u moet niet meerdere keren aanroepen TryStartNoGCRegion (na de eerste methodeaanroep, volgende aanroepen zullen niet slagen) en u mag niet verwachten dat aanroepen EndNoGCRegion slagen, alleen omdat de eerste aanroep is TryStartNoGCRegion geslaagd.