11
votes

C #: Dans quels cas devriez-vous nuler des références?

Le profileur CLR peut également révéler quelles méthodes allouent plus de stockage que prévu et peuvent découvrir des cas où vous gardez des références par inadvertance à des graphiques d'objet inutiles qui pourraient être récupérés par GC. (Un modèle de conception de problème courant est un cache logiciel ou une table de recherche d'éléments qui ne sont plus nécessaires ou sont sûrs à reconstituer ultérieurement. Il est tragique lorsqu'un cache conserve des graphiques d'objet au-delà de leur durée de vie utile. Soyez sûr de vous assurer de NULL OUT Références aux objets que vous n'avez plus besoin .) - écrire plus rapidement Code géré

Je ne pense pas que j'ai vraiment annulé une référence avant. Je suppose que vous n'avez pas toujours besoin de faire cela, mais je suppose qu'il y a aussi des moments où il est important de se rappeler de le faire. Mais quels cas est-ce? Quand devriez-vous nuler des références?


0 commentaires

3 Réponses :


11
votes

Il vous suffit de le faire lorsque la variable tenant la référence va rester « en vie », mais vous ne voulez pas la référence elle-même pour empêcher la collecte des ordures. En d'autres termes, si l'objet A contient une référence à l'objet B, et vous n'avez pas besoin B plus mais A reste en vie pour d'autres raisons. Un autre exemple courant est des variables statiques, qui sont « en vie » aussi longtemps que l'AppDomain est.

Pour les variables locales il de presque jamais eu besoin, parce que le GC peut détecter le dernier point possible dans le code où sera accessible une variable. Toutefois, si vous utilisez une variable déclarée en dehors d'une boucle au cours de la première itération, mais vous savez que vous ne aurez pas besoin pour les itérations suivantes, vous peut ensemble que null pour aider l'objet pour devenir admissible à GC précédemment.

Dans mon expérience, il est très rare de me retrouver dans cette situation. Je presque jamais ensemble de variables à délibère nulle pour le bien du GC. En général, toutes les variables membres au sein d'un objet sont « utiles » jusqu'à ce que l'objet lui-même devient admissible à GC. Si vous vous retrouvez avec des variables membres qui ne sont pas utile pour la vie entière de l'objet, vous pouvez voir si cela indique un problème avec la conception.


1 commentaires

Logique. Je pense que j'ai beaucoup fait de cette façon aussi, sans vraiment y penser.



4
votes

Il est important que vous ayez des objets de longue durée (comme l'exemple de cache dans votre devis) tenant des références à des objets de courte durée (comme les éléments de cache). D'autres exemples d'objets de longue durée pourraient être des objets Singleton, l'instance de formulaire principale dans une application Formulaires Windows, l'instance d'application d'une application ASP.NET, etc.

J'aimerais ajouter un autre pitful commun: des objets de courte durée de vie se souscrivant aux événements publiés par des objets de longue durée. Comme l'éditeur d'événement détient une référence à tous les abonnés, les abonnés (comme e. G. ASP.NET Page ou des instances de contrôle nécessaires uniquement pour les millisecondes) ne seront pas collectées si vous ne vous désabonnez pas.


1 commentaires

Un exemple particulièrement flagrigeant sont des contrôles thématiques sous les formulaires Windows (par exemple, Toolstrip ), qui enregistre avec des événements de changement de thème Windows lorsqu'ils deviennent visibles et ne se retrouvent pas si vous ne définissez pas visible sur false avant de les désirer. Si votre application crée et détruit beaucoup de ces objets, vous pouvez rencontrer des ennuis - surtout si vous vous attendez à ce que les objets que ces commandes contiennent des références pour obtenir des déchets perçus également. Je trotte cela chaque fois que le sujet se présente parce qu'il était profondément traumatisant.



1
votes

Vous devriez nuler des références pour l'objet dont vous n'en avez plus besoin lorsque vous savez qu'ils ne seront pas détestés autrement.

Si vous avez Livre efficace Java , Recherchez le point 5, il existe un exemple d'implémentation de la pile qui a des fuites de mémoire, car les références d'objets ne sont pas annulées. Si vous n'avez pas ce livre, vous pouvez regarder cette partie sur Google Books ici .


0 commentaires