Classe System.GC

Cet article fournit des remarques supplémentaires à la documentation de référence de cette API.

La GC classe contrôle le ramasse-miettes. Le garbage collector est un composant de l'environnement d'exécution .NET qui contrôle l’allocation et la libération de la mémoire managée. Les méthodes de cette classe ont une influence quand le nettoyage de mémoire 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 récupérateur de mémoire effectue le suivi et récupère les objets alloués en mémoire managée. Régulièrement, le récupérateur de mémoire réalise un nettoyage de mémoire pour récupérer la mémoire allouée aux objets pour lesquels il n’existe aucune référence valide. Le ramasse-miettes se déclenche automatiquement lorsqu’une demande de mémoire ne peut pas être satisfaite avec la mémoire libre disponible. Une application peut également forcer le nettoyage de mémoire à l’aide de la méthode Collect.

La collecte de déchets consiste en les étapes suivantes :

1. Le garbage collector recherche les objets managés référencés dans le code managé.
2. Le ramasse-miettes tente de finaliser les objets qui ne sont pas référencés.
3. Le ramasse-miettes 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 ramasse-miettes ne libère pas un objet s’il trouve une ou plusieurs références à l’objet dans le code géré. Toutefois, le ramasse-miettes 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é, à moins qu’il ne soit 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 remplaçant la méthode Object.Finalize ; toutefois, les types écrits en C# ou C++ implémentent des destructeurs, que les compilateurs transforment en un remplacement de Object.Finalize. Dans la plupart des cas, si un objet a un finaliseur, le ramasse-miettes le déclenche avant de libérer l’objet. Toutefois, le récupérateur de mémoire n’est pas obligé d’appeler les finaliseurs dans toutes les circonstances ; par exemple, la méthode SuppressFinalize empêche explicitement que le finaliseur d’un objet soit appelé. En outre, le récupérateur de mémoire n'est pas obligé d'utiliser un thread spécifique pour finaliser des objets, ni de garantir l'ordre dans lequel les finaliseurs sont appelés pour des objets qui se réfèrent les uns aux autres, mais qui sont autrement disponibles pour le nettoyage de mémoire.

Dans les scénarios où les ressources doivent être publiées à un moment spécifique, les classes peuvent implémenter l’interface IDisposable , qui contient la IDisposable.Dispose méthode qui effectue des tâches de gestion des ressources et de nettoyage. 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 nettoyer 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 récupérateur de mémoire dans l'environnement d'exécution commun prend en charge le vieillissement des objets grâce aux 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 ramasse-miettes prend en charge trois niveaux d’objets : niveaux 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 ramasse-miettes sur un ensemble spécifique de générations plutôt que d'exiger que le ramasse-miettes évalue toutes les générations. Les surcharges de la méthode Collect qui incluent un paramètre generation vous permettent de spécifier la génération la plus ancienne à récupérer.

Désactiver la collecte de déchets

Le collecteur de déchets prend en charge un mode de latence pour les régions sans GC, qui peut être utilisé pendant l'exécution de sections critiques où la collecte de déchets peut affecter négativement les performances d'une application. Le mode de latence de région sans GC nécessite que vous spécifiiez une quantité de mémoire pouvant être allouée sans interférence du récupérateur de mémoire. Si l'environnement d'exécution peut allouer cette mémoire, il n'effectuera pas de nettoyage de mémoire pendant l'exécution du code dans le chemin critique.

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

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