Classe System.GC

Cet article vous offre des remarques complémentaires à la documentation de référence pour cette API.

La GC classe contrôle le garbage collector. Le garbage collector est un composant Common Language Runtime qui contrôle l’allocation et la mise en production de la mémoire managée. Les méthodes de cette classe influencent quand le garbage collection est effectué sur un objet et lorsque les ressources allouées par un objet sont libérées. Les propriétés de cette classe fournissent des informations sur la quantité totale de mémoire disponible dans le système et la catégorie d’âge, ou génération, de la mémoire allouée à un objet.

Le garbage collector effectue le suivi et récupère les objets alloués en mémoire managée. Régulièrement, le garbage collector effectue un garbage collection pour récupérer la mémoire allouée aux objets pour lesquels il n’existe aucune référence valide. Le garbage collection se produit automatiquement lorsqu’une demande de mémoire ne peut pas être satisfaite à l’aide de la mémoire libre disponible. Une application peut également forcer le garbage collection à l’aide de la Collect méthode.

Le garbage collection se compose des étapes suivantes :

1. Le garbage collector recherche les objets managés référencés dans le code managé.
2. Le garbage collector tente de finaliser les objets qui ne sont pas référencés.
3. Le garbage collector libère les objets qui ne sont pas référencés et récupère leur mémoire.

Ressources non managées

Pendant un regroupement, le garbage collector ne libère pas un objet s’il trouve une ou plusieurs références à l’objet dans le code managé. Toutefois, le garbage collector ne reconnaît pas les références à un objet à partir d’un code non managé et peut libérer des objets utilisés exclusivement dans du code non managé, sauf si ce n’est explicitement empêché de le faire. La KeepAlive méthode fournit un mécanisme qui empêche le garbage collector de collecter des objets qui sont toujours utilisés dans du code non managé.

Outre les allocations de mémoire managée, les implémentations du garbage collector ne conservent pas d’informations sur les ressources détenues par un objet, telles que les handles de fichiers ou les connexions de base de données. Lorsqu’un type utilise des ressources non managées qui doivent être libérées avant que les instances du type soient récupérées, le type peut implémenter un finaliseur.

Dans la plupart des cas, les finaliseurs sont implémentés en substituant la Object.Finalize méthode ; toutefois, les types écrits en C# ou C++ implémentent des destructeurs, que les compilateurs transforment en remplacement de Object.Finalize. Dans la plupart des cas, si un objet a un finaliseur, le garbage collector l’appelle avant de libérer l’objet. Toutefois, le garbage collector n’est pas nécessaire pour appeler des finaliseurs dans toutes les situations ; par exemple, la SuppressFinalize méthode empêche explicitement le finaliseur d’un objet d’être appelé. En outre, le garbage collector n’est pas nécessaire pour utiliser un thread spécifique pour finaliser des objets, ou garantir l’ordre dans lequel les finaliseurs sont appelés pour les objets qui font référence les uns aux autres, mais qui sont autrement disponibles pour le garbage collection.

Dans les scénarios où les ressources doivent être publiées à un moment spécifique, les classes peuvent implémenter l’interfaceIDisposable, qui contient la IDisposable.Dispose méthode qui effectue la gestion des ressources et les tâches de propre up. Les classes qui implémentent Dispose doivent spécifier, dans le cadre de leur contrat de classe, si et quand les consommateurs de classes appellent la méthode pour propre l’objet. Le garbage collector n’appelle pas par défaut la Dispose méthode . Toutefois, les implémentations de la Dispose méthode peuvent appeler des méthodes dans la GC classe pour personnaliser le comportement de finalisation du garbage collector.

Pour plus d’informations sur la finalisation de l’objet et le modèle de suppression, consultez Nettoyage des ressources non managées.

Vieillissement de l’objet et générations

Le garbage collector dans le Common Language Runtime prend en charge le vieillissement des objets à l’aide de générations. Une génération est une unité de mesure de l’âge relatif des objets en mémoire. Le numéro de génération ou l’âge d’un objet indique la génération à laquelle appartient un objet. Les objets créés plus récemment font partie des générations plus récentes et ont des nombres de génération inférieurs aux objets créés plus tôt dans le cycle de vie de l’application. Les objets de la génération la plus récente sont de génération 0. Cette implémentation du garbage collector prend en charge trois générations d’objets, générations 0, 1 et 2. Vous pouvez récupérer la valeur de la MaxGeneration propriété pour déterminer le nombre maximal de génération pris en charge par le système.

Le vieillissement de l’objet permet aux applications de cibler le garbage collection à un ensemble spécifique de générations plutôt que de demander au garbage collector d’évaluer toutes les générations. Les surcharges de la Collect méthode qui incluent un generation paramètre vous permettent de spécifier la génération la plus ancienne à collecter.

Interdire le garbage collection

Le garbage collector prend en charge un mode de latence de région GC qui peut être utilisé pendant l’exécution de chemins critiques dans lesquels le garbage collection peut affecter les performances d’une application. Aucun mode de latence de région GC ne nécessite que vous spécifiiez une quantité de mémoire qui peut être allouée sans interférence du garbage collector. Si le runtime peut allouer cette mémoire, le runtime n’effectue pas de garbage collection pendant l’exécution du code dans le chemin critique.

Vous définissez le début du chemin critique d’aucune région GC en appelant l’une des surcharges du TryStartNoGCRegion. Vous spécifiez la fin de son chemin critique en appelant la EndNoGCRegion méthode.

Vous ne pouvez pas imbriquer les appels à la TryStartNoGCRegion méthode, et vous devez uniquement appeler la EndNoGCRegion méthode si le runtime n’est actuellement pas en mode de latence de région GC. En d’autres termes, vous ne devez pas appeler TryStartNoGCRegion plusieurs fois (après l’appel de la première méthode, les appels suivants ne réussissent pas), et vous ne devez pas vous attendre à EndNoGCRegion ce que les appels réussissent simplement parce que le premier appel a TryStartNoGCRegion réussi.