32 votes

Est-il judicieux de définir obj = null (Nothing) dans Dispose ()?

Est-il judicieux de définir l'objet personnalisé sur null ( Nothing dans VB.NET) dans la méthode Dispose() ? Cela pourrait-il empêcher les fuites de mémoire ou est-il inutile?!

Prenons deux exemples:

 public class Foo : IDisposable
{
    private Bar bar; // standard custom .NET object

    public Foo(Bar bar) {
        this.bar = bar;
    }
    public void Dispose() {
        bar = null; // any sense?
    }
}

public class Foo : RichTextBox
{
    // this could be also: GDI+, TCP socket, SQl Connection, other "heavy" object
    private Bitmap backImage; 

    public Foo(Bitmap backImage) {
        this.backImage = backImage;
    }

    protected override void Dispose(bool disposing) {
        if (disposing) {
            backImage = null;  // any sense?
        }
    }
}
 

24voto

Marc Gravell Points 482669

Personnellement, j'ai tendance à; pour deux raisons:

  • cela signifie que si quelqu'un a oublié de libérer l' Foo (peut-être à partir d'un événement) tout en aval des objets (un Bitmap dans ce cas) peut encore être collectées (à un certain moment dans l'avenir, chaque fois que le GC se sent comme elle); il est probable que c'est juste un peu wrapper autour d'une ressource non managée, mais chaque petit aide.
    • J'ai vraiment n'aime pas accidentellement en gardant la totalité de l'objet graphique traîner tout simplement parce que l'utilisateur a oublié de décrocher un événement; IDisposable est à portée de main "presque-tuer" switch - pourquoi ne pas la détacher de tout ce qui est disponible?
  • plus important encore, je peux sans-gêne maintenant, utilisez ce champ pour vérifier (dans des méthodes, etc) pour l'élimination, en jetant un ObjectDisposedException si il est null

20voto

Brian Rasmussen Points 68853

Le but de Dispose() est de permettre le nettoyage des ressources non gérées par le garbage collector. Les objets sont pris en charge par GC, il n'y a donc vraiment pas besoin de le faire.

4voto

Dave Markle Points 44637

C'est à peu près inutile. Paramètre à NULL de retour dans la vieille COM/VB jours, je crois, serait de décrémentation votre compte de référence.

Ce n'est pas vrai avec .NET. Lorsque vous définissez la barre null, vous n'avez pas fait de détruire ou de libérer quoi que ce soit. Vous êtes simplement en changeant la référence au fait que la barre de points, à partir de votre objet à "null". Votre objet existe toujours (bien que maintenant, car rien de ce qui se réfère à elle, elle finira par être le garbage collector). À quelques exceptions près, et dans la plupart des cas, c'est la même chose qui se serait passé si vous tout simplement pas fait Foo IDisposable en premier lieu.

Le grand but de IDisposable est de vous permettre de libérer non géré les ressources, comme les sockets TCP ou les connexions SQL, ou quoi que ce soit. Ceci est habituellement fait en appelant tout le nettoyage de la fonction le non géré ressource fournit, pas par la définition de la référence à "null".

1voto

Marek Points 5077

Cela peut avoir du sens si vous voulez en quelque sorte à prévenir les éliminés appartenant à l'instance pour être ré-utilisé.

Lorsque vous définissez les références à jetables champs à null, vous avez la garantie de ne pas utiliser les instances de plus.

Vous n'obtiendrez pas d' ObjectDisposedException ou de tout autre état non valide causés par l'utilisation de la propriété cédée exemple (vous pouvez obtenir de l' NullReferenceException si vous ne cochez pas les valeurs null).

Cela peut ne pas faire sens pour vous aussi longtemps que tous IDisposable des objets ont un IsDisposed de la propriété et/ou de jeter ObjectDisposedException si elles sont utilisées après ils sont éliminés - certains peuvent contrevenir à ce principe, à la valeur null peut prévenir les effets indésirables de se produire.

1voto

BeowulfOF Points 3737

En C# paramètre un objet à la valeur null est juste la libération de la référence à l'objet.

Ainsi, il est théoriquement mieux pour libérer la référence sur les objets gérés dans un Jetez-Méthode en C#, mais seulement la possibilité pour le gouvernement pour recueillir de l'objet référencé avant de l'objet supprimé est recueillie. Depuis les deux plus susceptibles d'être collectées dans la même course, le GC sera très probablement reconnaître, que l'objet référencé n'est référencé par un aliéné type, de sorte que les deux peuvent être collectées.

Aussi la nécessité de libérer la référence est très faible, étant donné que tous les membres de votre classe jetable doit lever une exception si la classe est alreay éliminés. Donc pas d'accès à votre objet référencé par la réussite après l'élimination référencé dans la méthode.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X