Objets de paramètre à Null/Nothing après utilisation dans .NET

Question

Devriez-vous mettre tous les objets d' null (Nothing dans VB.NET) une fois que vous avez fini avec eux?

Je comprends que dans .NET, il est essentiel de disposer de toutes les instances des objets qui implémentent l' IDisposable interface pour libérer quelques ressources bien que l'objet peut-être encore quelque chose après il est éliminé (d'où l' isDisposed propriété dans les formulaires), je suppose qu'il peut encore résider dans la mémoire ou au moins en partie?

Je sais aussi que quand un objet est hors de portée, il est alors marqué pour la collection prêt pour le prochain passage du garbage collector (même si cela peut prendre du temps).

Donc, avec cela à l'esprit la mise à null de la vitesse du système en libérant de la mémoire qu'il n'a pas de travail qu'il n'est plus dans le champ d'application et sont-ils de mauvais effets secondaires?

Articles MSDN ne jamais faire cela dans les exemples et actuellement je fais ce que je ne peux pas voir le mal. Cependant, j'ai trouvé un mélange d'opinions afin de tous les commentaires sont utiles.

Answer 1

Karl est tout à fait exact, il n'est pas nécessaire de définir des objets à null après l'utilisation. Si un objet implémente IDisposable, juste assurez-vous vous appelez IDisposable.Dispose() lorsque vous avez terminé avec cet objet (enveloppé dans un try..finally, ou, using() de l'îlot). Mais même si vous ne vous souvenez pas de l'appeler Dispose(), le finaliser la méthode sur l'objet doit être appelant Dispose() pour vous.

Je pensais que c'était un bon traitement:

Creuser dans IDisposable

et ce

La Compréhension IDisposable

Il n'y a aucun intérêt à essayer de deuxième deviner le gouvernement du canada et ses stratégies de gestion parce que c'est l'auto tuning et opaque. Il y avait une bonne discussion sur le fonctionnement interne avec Jeffrey Richter sur Dot Net Rochers ici: Jeffrey Richter, sur le Modèle de la Mémoire de Windowset Richters livre CLR via C# chapitre 20 est un excellent traitement:

Answer 2

Une autre raison pour éviter de mettre des objets de valeur null lorsque vous avez terminé avec eux, c'est qu'il peut effectivement garder en vie plus longtemps.

par exemple

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is now eligible for garbage collection         

    // ... rest of method not using 'someType' ...
}

permettra à l'objet visé par someType à GC avais après l'appel à "DoSomething" mais

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is NOT eligible for garbage collection yet
    // because that variable is used at the end of the method         

    // ... rest of method not using 'someType' ...
    someType = null;
}

peut parfois garder l'objet en vie jusqu'à la fin de la méthode. L' équipe généralement optimisés à l'écart de l'affectation à la valeur null, alors les deux bits de code de finir par être le même.

Answer 3

Ne ne les objets nuls. Vous pouvez consulter http://codebetter.com/blogs/karlseguin/archive/2008/04/27/foundations-of-programming-pt-7-back-to-basics-memory.aspx pour plus d’informations, mais définissant des choses sur null ne fait rien, sauf de salir votre code.

Answer 4

En général, il n'y a pas besoin d'objets null après l'utilisation, mais dans certains cas je trouve que c'est une bonne pratique.

Si un objet implémente IDisposable et est stocké dans un champ, je pense que c'est bon null, juste pour éviter à l'aide de l'objet supprimé. Les bugs du tri suivant peut être douloureux:

this.myField.Dispose();

C'est bon à null le terrain après l'élimination, et obtenir une NullPtrEx droit à la ligne où le champ est utilisé à nouveau. Sinon, vous risquez de rencontrer quelques cryptique bug sur la ligne (selon exactement ce DoSomething n').

Answer 5

Aussi :