Réglage objets à Null / Rien après utilisation dans .NET

voix
173

Si vous régler tous les objets à null( Nothingune fois que vous avez terminé avec eux en VB.NET)?

Je comprends que dans .NET , il est essentiel de disposer de toutes les instances d'objets qui mettent en œuvre l' IDisposableinterface pour libérer des ressources bien que l'objet peut encore être quelque chose après il est disposé ( d' où la isDisposedpropriété sous des formes), 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 ensuite marqué pour la collecte prête pour le passage suivant du collecteur d'ordures (bien que cela peut prendre du temps).

Donc , avec cela à l' esprit sera mise à nullaccélérer le système libérant la mémoire car il ne doit pas travailler qu'il est plus portée et sont - ils des effets secondaires néfastes?

articles MSDN ne le font dans les exemples et actuellement je fais ce que je ne vois pas le mal. Cependant, je suis venu à travers un mélange d'opinions afin de commentaires sont utiles.

Créé 05/08/2008 à 21:14
source utilisateur
Dans d'autres langues...                            


15 réponses

voix
66

Karl est tout à fait correct, il n'y a pas besoin d'objets à mettre nulle après utilisation. Si un objet implémente IDisposable, assurez - vous que vous appelez IDisposable.Dispose()lorsque vous avez terminé avec cet objet (enveloppé dans un try.. finally, ou un using()bloc). Mais même si vous ne vous souvenez pas d'appeler Dispose(), la méthode Finaliser sur l'objet devrait appeler Dispose()pour vous.

Je pensais que c'était un bon traitement:

Creuser dans IDisposable

et ça

comprendre IDisposable

Il n'y a pas d'essayer de deviner la GC et ses stratégies de gestion , car il est le réglage auto et opaque. Il y avait une bonne discussion sur le fonctionnement interne avec Jeffrey Richter sur Rocks Dot Net ici: Jeffrey Richter sur le modèle mémoire Windows et Richters livre CLR via C # chapitre 20 a un traitement:

Créé 05/08/2008 à 21:56
source utilisateur

voix
33

Une autre raison d'éviter des objets à mettre nulle lorsque vous avez terminé avec eux est qu'il peut effectivement les maintenir 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 UnType à GC'd 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. Le JIT est généralement optimisé à une distance l'affectation à null , si les deux bits de code finissent par être les mêmes.

Créé 15/08/2008 à 15:43
source utilisateur

voix
15

Non objets ne pas nul. 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 remettre les choses null ne fera rien, sauf votre code sale.

Créé 05/08/2008 à 21:23
source utilisateur

voix
7

En général, il n'y a pas besoin de null objets après 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 qu'il est bon de null, juste pour éviter d'utiliser l'objet disposé. Les insectes du genre suivant peuvent être douloureux:

this.myField.Dispose();
// ... at some later time
this.myField.DoSomething();

Il est bon de null le terrain après l'élimination, et obtenir un droit NullPtrEx à la ligne où le champ est utilisé à nouveau. Dans le cas contraire, vous pourriez rencontrer un bug cryptique la ligne (en fonction exactement ce que fait DoSomething).

Créé 09/08/2008 à 12:16
source utilisateur

voix
7

Aussi:

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of
Créé 05/08/2008 à 21:37
source utilisateur

voix
6

Il y a des chances que votre code est pas structuré assez bien si vous sentez le besoin de les nullvariables.

Il y a plusieurs façons de limiter la portée d'une variable:

Comme l'a mentionné Steve Tranby

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of

De même, vous pouvez simplement utiliser des accolades:

{
    // Declare the variable and use it
    SomeObject object = new SomeObject()
}
// The variable is no longer available

Je trouve que l'utilisation des accolades sans « tête » pour nettoyer vraiment le code et le rendre plus compréhensible.

Créé 09/08/2008 à 13:13
source utilisateur

voix
5

En général pas besoin de mettre à zéro. Mais supposons que vous avez une fonctionnalité Réinitialiser dans votre classe.

Ensuite, vous pouvez le faire, parce que vous ne voulez pas appeler deux fois disposer, car certains des Éliminez ne peut pas être mis en œuvre correctement et jeter exception System.ObjectDisposed.

private void Reset()
{
    if(_dataset != null)
    {
       _dataset.Dispose();
       _dataset = null;
    }
    //..More such member variables like oracle connection etc. _oraConnection
 }
Créé 17/04/2012 à 09:55
source utilisateur

voix
4

Le seul moment où vous devez définir une variable à null est lorsque la variable ne va pas hors de portée et que vous ne avez plus besoin des données qui y sont associées. Sinon, il n'y a pas besoin.

Créé 05/08/2008 à 21:32
source utilisateur

voix
3

ce genre de « il n'y a pas besoin de fixer des objets à NULL après utilisation » n'est pas tout à fait exact. Il y a des moments dont vous avez besoin NULL la variable après le disposer.

Oui, vous devez toujours appeler .Dispose()ou .Close()sur tout ce qui a quand vous avez terminé. Que ce soit le fichier poignées, les connexions de base de données ou des objets à usage unique.

Indépendamment de ce qui est le modèle très pratique de LazyLoad.

Dire que je l' ai et instancié ObjAde class A. Class Aa une propriété publique appelée PropBde class B.

En interne, PropButilise la variable privée _Bet par défaut NULL. Quand PropB.Get()est utilisé, il vérifie si _PropBest nulle et si elle est, ouvre les ressources nécessaires pour instancier un Ben _PropB. Il retourne ensuite _PropB.

Pour mon expérience, c'est un truc vraiment utile.

Lorsque le besoin de null est disponible en est si vous rétablissez ou modification d' une certaine façon que le contenu de _PropBétaient l'enfant des valeurs précédentes A, vous devez vous débarrasser et Null en _PropBsorte LazyLoad peut remettre à chercher la bonne valeur si le code l' exige.

Si vous ne le faites _PropB.Dispose()et peu attendre après la vérification nul pour LazyLoad pour réussir, il ne sera pas nul, et vous regarderez des données périmées. En effet, vous devez Null après Dispose()juste pour être sûr.

Je souhaite que c'était autrement, mais j'ai le code obtenu droit maintenant ce comportement présentant après Dispose()sur _PropBet à l' extérieur de la fonction d'appel qui a fait l'Dispose (et donc presque hors de portée), l'hélice privée est toujours pas nulle, et les données périmées est toujours là.

Finalement, la propriété sera disposé null, mais qui a été non-déterministe de mon point de vue.

La raison principale, comme dbkk fait allusion est que le conteneur parent ( ObjAavec PropB) maintient l'instance de _PropBportée, en dépit de la Dispose().

Créé 11/04/2012 à 02:12
source utilisateur

voix
1

Jetez un oeil à cet article ainsi: http://www.codeproject.com/KB/cs/idisposable.aspx

Pour la plupart, la fixation d'un objet à nul n'a aucun effet. Le seul moment où vous devez être sûr de le faire est si vous travaillez avec un « grand objet », ce qui est un plus grand que 84K taille (comme bitmaps).

Créé 17/08/2008 à 05:46
source utilisateur

voix
1

Il y a des cas où il est logique de références null. Par exemple, lorsque vous écrivez une collection - comme une file d'attente prioritaire - et par votre contrat, vous ne devriez pas garder ces objets vivants pour le client après que le client les a retirés de la file d'attente.

Mais ce genre de chose importe que dans les collections à vie longue. Si la file d'attente ne va pas survivre à la fin de la fonction, il a été créé en, il importe beaucoup moins.

Sur l'ensemble, vous devriez vraiment pas la peine. Laissez le compilateur et GC faire leur travail afin que vous puissiez faire le vôtre.

Créé 05/08/2008 à 21:46
source utilisateur

voix
0

Je pense que la mise en quelque chose à zéro est en désordre. Imaginez un scénario dans lequel l'élément étant mis à dire est maintenant exposée par la propriété. Maintenant, est en quelque sorte un morceau de code utilise accidentellement cette propriété après que l'élément est disposé, vous obtiendrez une exception de référence null qui nécessite une enquête pour savoir exactement ce qui se passe.

Je crois disposables-cadres permet ObjectDisposedException jeter ce qui est plus significatif. Ne pas fixer ces éléments sur nul serait mieux alors pour cette raison.

Créé 13/09/2019 à 12:52
source utilisateur

voix
0

Stephen Cleary explique très bien dans ce message: Dois - je configurer des variables de valeur nulle pour aider la collecte des ordures?

Dit:

La réponse, pour le Impatient Oui, si la variable est un champ statique, ou si vous écrivez une méthode dénombrable (à l'aide de retour de rendement) ou une méthode asynchrone (en utilisant async et attendre). Dans le cas contraire, non.

Cela signifie que dans les méthodes régulières (non dénombrable et non asynchrone), vous ne définissez pas de variables locales, les paramètres de la méthode, ou champs d'instance à null.

(Même si vous implémentez IDisposable.Dispose, vous devriez toujours pas définir des variables à null).

La chose importante que nous devons considérer est les champs statiques .

Les champs statiques sont toujours des objets racine , ils sont toujours considérés comme « vivant » par le garbage collector. Si un champ statique fait référence à un objet qui n'est plus nécessaire, il doit être réglé sur null afin que le garbage collector traitera comme admissible à la collecte.

La configuration des champs statiques null est vide de sens si l'ensemble du processus est en cours d'arrêt. Le tas entier est sur le point d'être déchets collectés à ce moment-là, y compris tous les objets racine.

blockquote

Conclusion:

Les champs statiques; C'est à peu près ça. Tout le reste est une perte de temps.

Créé 27/03/2019 à 00:50
source utilisateur

voix
0

Je crois par la conception des GC implementors, vous ne pouvez pas accélérer le GC avec l' annulation. Je suis sûr qu'ils vous préférez ne pas vous inquiéter avec comment / quand GC fonctionne - le traiter comme celui - ci omniprésent Être protéger et de veiller sur et pour vous ... (arcs tête vers le bas, lève le poing vers le ciel) .. .

Personnellement, je mets souvent explicitement variables à zéro quand je suis fait avec eux comme une forme de documentation auto. Je ne déclare pas, utiliser, puis réglé sur null plus tard - je Null immédiatement après qu'ils ne sont plus nécessaires. Je dis, explicitement: « Je suis officiellement fait avec vous ... être allé ... »

Est nécessaire dans une annuler langue GC'd? Non . Est - il utile pour le GC? Peut - être que oui, peut - être pas, ne sais pas pour certains, par la conception que je ne peux pas le contrôler, et quelle que soit la réponse d'aujourd'hui avec cette version ou que les mises en œuvre futures du GC pourraient changer la réponse au - delà de mon contrôle. De plus , si / quand Nulling est optimisé sur il est un peu plus d'une fantaisie commentaire si vous voulez.

Je suppose que si elle fait mon intention plus claire à l'autre pauvre fou qui suit mes traces, et si elle « pourrait » potentiellement aider GC parfois, il vaut le coup pour moi. La plupart du temps , il me fait me sentir bien rangé et clair, et Mongo aime se sentir bien rangé et clair. :)

Je regarde comme ceci: Les langages de programmation existent pour permettre aux gens de donner aux autres une idée d'intention et un compilateur une demande d'emploi de ce qu'il faut faire - le compilateur convertit cette demande dans une autre langue (parfois plusieurs) pour une unité centrale de traitement - l'unité centrale de traitement (s) pourrait donner un coup de klaxon langue que vous avez utilisé, vos paramètres de l'onglet, des commentaires, des emphases stylistiques, les noms de variables, etc. - une unité centrale de traitement est tout au sujet du flux de bits qui indique quel registres et opcodes et emplacements de mémoire à tripoter. Beaucoup de choses écrites dans le code ne se transforment pas en ce qui est consommé par la CPU dans la séquence que nous avons spécifié. Notre C, C ++, C #, Lisp, Babel, assembleur ou ce qui est la théorie plutôt que la réalité, écrit comme un énoncé des travaux. Ce que vous voyez est ce que vous obtenez pas, oui, même en langage assembleur.

Je comprends l'état d'esprit des « choses inutiles » (comme des lignes vides) « ne sont que du bruit et encombrer le code. » Cela m'a été plus tôt dans ma carrière; Je reçois tout à fait ça. A ce stade, je penche vers ce qui rend le code plus clair. Il est pas comme j'ajoute même 50 lignes de « bruit » à mes programmes - il est quelques lignes ici ou là.

Il y a des exceptions à toute règle. Dans les scénarios avec la mémoire volatile, mémoire statique, les conditions de course, singletons, utilisation des données « périmées » et tout ce genre de pourriture, c'est différent: vous devez gérer votre propre mémoire, verrouillage et réduire à néant comme à propos, car la mémoire ne fait pas partie de l'univers GC'd - espérons-tout le monde comprend. Le reste du temps avec les langues GC'd il est une question de style plutôt que par nécessité ou un gain de performances garanties.

A la fin de la journée, assurez-vous de comprendre ce qui est admissible à GC et ce qui est pas; verrouiller, d'en disposer, et d'annuler de façon appropriée; cire, la cire hors; Inspire, expire; et pour tout ce que je dis: Si on se sent bien, faites-le. Votre kilométrage peut varier ... comme il se doit ...

Créé 10/05/2016 à 13:07
source utilisateur

voix
-1

Certains objets supposons que la .dispose()méthode qui force la ressource à supprimer de la mémoire.

Créé 05/08/2008 à 21:21
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more