La bonne utilisation de l'interface IDisposable

Je sais de lecture la documentation de Microsoft que le "primaire" de l'utilisation de la IDisposable interface est de nettoyer les ressources non managées.

Pour moi, "non géré" signifie des choses comme des connexions de base de données, des sockets, des poignées de fenêtre, etc. Mais, j'ai vu du code où l' Dispose() méthode est mise en œuvre à la libre géré ressources, qui semble redondant pour moi, depuis le garbage collector devrait prendre soin de cela pour vous.

Par exemple:

public class MyCollection : IDisposable
{
    private List<String> _theList = new List<String>();
    private Dictionary<String, Point> _theDict = new Dictionary<String, Point>();

    //Die, clear it up! (free unmanaged resources)
    public void Dispose()
    {
        _theList.clear();
        _theDict.clear();
        _theList = null;
        _theDict = null;
    }

Ma question est, est-ce faire le garbage collector libérer la mémoire utilisée par MyCollection plus vite qu'il le ferait normalement?

modifier: Donc, beaucoup de gens ont posté quelques bons exemples de l'utilisation de IDisposable pour nettoyer les ressources non managées comme des connexions de base de données et d'images. Mais supposons que _theList dans le code ci-dessus figurant un million de chaînes, et que vous vouliez pour libérer de la mémoire maintenant, plutôt que d'attendre que le garbage collector. Serait le code ci-dessus le réaliser?

J'aime la accepté de répondre parce que vous dire la bonne "pattern" de l'aide IDisposable, mais comme l'OP a dit, dans son édition, il ne répond pas à sa destinée question. IDisposable ne fait pas appel de la GC, c'est juste les "marques" à un objet destructible. Mais quelle est la véritable façon de libérer de la mémoire "right now" au lieu d'attendre pour les GC à coup de pied? Je pense que cette question mérite un examen plus approfondi.
IDisposable ne marque pas de quoi que ce soit. Le Dispose méthode fait ce qu'il a à faire pour nettoyer les ressources utilisées par l'instance. Cela n'a rien à voir avec le GC.
Je pense que vous avez mal compris ma question. Assumer ma classe implémente IDisposable et dans ma classe, je suis en utilisant une très grande liste de tableaux ou de quelque autre objet géré que j'ai mis à l'(marque comme) null lorsque l'Éliminer(true) est appelée sur une instance de ma classe. Maintenant, selon le modèle, ce que je fais ici est le marquage de la liste de tableaux de référence à null, mais la liste de tableaux d'objets de données dans la mémoire jusqu'à ce que le GC coups de pied dans ce qui est non-déterministe. Donc, la question est de savoir comment gratuit ce non référencées bloc de mémoire immédiatement et de façon déterministe.
encore une fois, vous êtes malentendu IDisposable. Il n'a rien à voir avec la libération de la mémoire. En outre, vous ne devez pas mettre votre référence à la valeur null à tous. Le laisser seul et de laisser le GC faire son travail.
Je ne comprends IDisposable. Et c'est pourquoi j'ai dit que l'on a accepté de répondre à ne pas répondre à l'OP est prévu à la question(et le suivi edit) si IDisposable aidera dans <i>la libération de la mémoire</i>. Depuis IDisposable n'a rien à voir avec la libération de la mémoire, de ressources, alors comme vous l'avez dit, il n'est pas nécessaire de définir la gestion des références à null, qui est ce que l'OP a été fait dans son exemple. Ainsi, la bonne réponse à sa question est "Non, ce n'est pas les aider à libérer de la mémoire plus rapide. En fait, il n'a pas d'aider à libérer de la mémoire, mais seulement de ressources". Mais de toute façon, merci pour vos commentaires.
si c'est le cas, alors vous ne devriez pas avoir dit "IDisposable ne fait pas appel de la GC, c'est juste les "marques" à un objet destructible"
Il n'y a aucun moyen de garantie de libérer de la mémoire de façon déterministe. Vous pourriez l'appeler GC.Collect(), mais c'est une demande polie, pas une demande. Tous les threads en cours d'exécution doit être suspendu pour la collecte des ordures à procéder - lire sur le concept de .NET points de restauration si vous voulez en savoir plus, par exemple, msdn.microsoft.com/en-us/library/678ysw69(v=vs. 110).aspx . Si un thread ne peut pas être suspendu, par exemple, parce qu'il y a un appel dans le code non managé, GC.Collect() peut ne rien faire du tout.

InformationsquelleAutor cwick | 2009-02-11

.net c#garbage-collection idisposable

2534

Le point de Jeter est pour libérer des ressources non managées. Il doit être fait à un certain point, sinon ils ne seront jamais nettoyé. Le garbage collector ne sais pas comment appeler DeleteHandle() sur une variable de type IntPtr, il ne sait pas si ou non il a besoin de faire appel DeleteHandle().

Note: qu'est Ce qu'un non géré ressources? Si vous avez trouvé dans le Microsoft .NET Framework: il est géré. Si vous êtes allé farfouillé MSDN vous-même, il est géré. Tout ce que vous avez utilisé P/Invoke appels à obtenir à l'extérieur de l'confortable monde de tout ce qui est disponible pour vous dans le .NET Framework est non géré – et maintenant, vous êtes responsable du nettoyage.

L'objet que vous avez créé doit exposer certains méthode, que le monde extérieur peut faire appel, afin de nettoyer les ressources non managées. La méthode peut être le nom que vous voulez:
```
public void Cleanup()
```
ou
```
public void Shutdown()
```
Mais il y a un nom normalisé pour cette méthode:
```
public void Dispose()
```
Il y a même une interface créée, IDisposable, qui a une seule méthode:
```
public interface IDisposable
{
   void Dispose()
}
```
Afin de vous rendre votre objet d'exposer la IDisposable interface, et de cette façon vous promets que vous avez écrit que la seule méthode pour nettoyer vos ressources non managées:
```
public void Dispose()
{
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);
}
```
Et vous avez terminé. Sauf que vous pouvez faire mieux.

Que si votre objet a alloué une 250MB Système.De dessin.Bitmap (c'est à dire l' .NET géré classe Bitmap) comme une sorte de mémoire tampon de trame? Bien sûr, cela est géré .NET de l'objet, et le garbage collector gratuit. Mais voulez-vous vraiment quitter 250 MO de mémoire juste assis là en attente pour le garbage collector de finalement venir et de les libérer? Que faire si il y a un ouvrir la connexion à la base? Certes, nous ne voulons pas que la connexion séance ouverte, en attente pour le GC pour finaliser l'objet.

Si l'utilisateur a appelé Dispose() (ce qui signifie qu'ils ne sont plus du plan d'utilisation de l'objet), pourquoi ne pas se débarrasser de ceux gaspillage des bitmaps et des connexions de base de données?

Alors maintenant, nous allons:
- se débarrasser de ressources non managées (parce qu'il faut), et
- se débarrasser de la gestion des ressources (parce que nous voulons être utile)
Donc, nous allons mettre à jour notre Dispose() méthode pour se débarrasser de ces objets gérés:
```
public void Dispose()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //Free managed resources too
   if (this.databaseConnection != null)
   {
      this.databaseConnection.Dispose();
      this.databaseConnection = null;
   }
   if (this.frameBufferImage != null)
   {
      this.frameBufferImage.Dispose();
      this.frameBufferImage = null;
   }
}
```
Et c'est tout bon, sauf que vous pouvez faire mieux!

Que faire si la personne oublié appeler Dispose() sur votre objet? Alors qu'ils seraient à la fuite de certains non géré de ressources!

Remarque: Ils ne fuit pas géré ressources, parce que finalement le garbage collector se déroulera, sur un thread d'arrière-plan, et de libérer la mémoire associée à aucun des objets inutilisés. Il s'agit de votre objet, et tout des objets gérés que vous utilisez (par exemple, la Bitmap et la DbConnection).

Si la personne a oublié d'appeler Dispose(), nous pouvons encore sauver leur bacon! Nous avons encore un moyen de l'appeler pour: lorsque le garbage collector, enfin, se déplace à libérer (c'est à dire la finalisation) de notre objet.

Remarque: Le garbage collector sera finalement libre de tous les objets gérés.
Quand il le fait, il appelle la Finalize
méthode sur l'objet. Le GC ne savent pas, ou
de soins, sur votre Disposer méthode.
C'était juste un nom que nous avons choisi pour
une méthode que nous appelons lorsque l'on veut obtenir
débarrasser de non géré choses.

La destruction de notre objet par le Garbage collector est le parfait temps de libre ces satanés des ressources non managées. Nous faisons cela en remplaçant la Finalize() méthode.

Remarque: En C#, vous n'avez pas explicitement remplacer le Finalize() méthode.
Vous écrivez une méthode qui ressemble un destructeur C++, et la
compilateur prend que pour être votre mise en œuvre de la Finalize() méthode:
```
~MyObject()
{
    //we're being finalized (i.e. destroyed), call Dispose in case the user forgot to
    Dispose(); //<--Warning: subtle bug! Keep reading!
}
```
Mais il y a un bug dans le code. Vous voyez, le garbage collector s'exécute sur un thread d'arrière-plan; vous ne savez pas l'ordre dans lequel les deux objets sont détruits. Il est tout à fait possible que, dans votre Dispose() code, le géré objet que vous essayez de vous débarrasser de (parce que tu voulais être utile) n'est plus: il y a
```
public void Dispose()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.gdiCursorBitmapStreamFileHandle);

   //Free managed resources too
   if (this.databaseConnection != null)
   {
      this.databaseConnection.Dispose(); //<-- crash, GC already destroyed it
      this.databaseConnection = null;
   }
   if (this.frameBufferImage != null)
   {
      this.frameBufferImage.Dispose(); //<-- crash, GC already destroyed it
      this.frameBufferImage = null;
   }
}
```
Donc, ce que vous avez besoin est une façon pour Finalize() dire Dispose() qu'il devrait touchez pas réussi ressources (parce qu'ils pourrait ne pas être là plus), tout en libérant des ressources non managées.

Au modèle standard pour ce faire est d'avoir Finalize() et Dispose() la fois d'un troisième(!) méthode; où l'on passe un Booléen disant: si vous appelez à partir de Dispose() (par opposition à Finalize()), ce qui signifie qu'il est sûr de gratuit ressources gérées.

Ce interne méthode pourrait être donné quelques arbitraire nom comme "CoreDispose", ou "MyInternalDispose", mais c'est la tradition de l'appeler Dispose(Boolean):
```
protected void Dispose(Boolean disposing)
```
Mais plus utile de nom de paramètre peut être:
```
protected void Dispose(Boolean itIsSafeToAlsoFreeManagedObjects)
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //Free managed resources too, but only if I'm being called from Dispose
   //(If I'm being called from Finalize then the objects might not exist
   //anymore
   if (itIsSafeToAlsoFreeManagedObjects)  
   {    
      if (this.databaseConnection != null)
      {
         this.databaseConnection.Dispose();
         this.databaseConnection = null;
      }
      if (this.frameBufferImage != null)
      {
         this.frameBufferImage.Dispose();
         this.frameBufferImage = null;
      }
   }
}
```
Et vous changez la mise en œuvre de la IDisposable.Dispose() méthode:
```
public void Dispose()
{
   Dispose(true); //I am calling you from Dispose, it's safe
}
```
et votre finaliseur à:
```
~MyObject()
{
   Dispose(false); //I am *not* calling you from Dispose, it's *not* safe
}
```
Note: Si votre objet descend d'un objet qui implémente Dispose, alors n'oubliez pas d'appeler leur base méthode dispose lorsque vous remplacez les Éliminer:
```
public override void Dispose()
{
    try
    {
        Dispose(true); //true: safe to free managed resources
    }
    finally
    {
        base.Dispose();
    }
}
```
Et c'est tout bon, sauf que vous pouvez faire mieux!

Si l'utilisateur appelle Dispose() sur votre objet, puis tout a été nettoyé. Plus tard, lorsque le garbage collector vient le long et les appels de Finaliser, il va alors appeler Dispose de nouveau.

Ce n'est pas seulement inutile, mais si votre objet a ordure des références à des objets que vous avez déjà éliminés de la dernier appel à Dispose(), que vous allez essayer de les disposer à nouveau!

Vous remarquerez que dans mon code j'ai eu soin de supprimer les références à des objets que j'ai cédé, je n'ai pas essayer d'appeler Dispose à bord d'une jonque de référence de l'objet. Mais cela n'empêche pas un bug subtil rampant dans.

Lorsque l'utilisateur appelle Dispose(): la poignée CursorFileBitmapIconServiceHandle est détruit. Plus tard, lorsque le garbage collector est exécuté, il va tenter de détruire le même handle de nouveau.
```
protected void Dispose(Boolean iAmBeingCalledFromDisposeAndNotFinalize)
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle); //<--double destroy 
   ...
}
```
La façon de résoudre ce problème est de dire que le garbage collector qu'il n'a pas besoin de s'embêter à la finalisation de l'objet de ses ressources ont déjà été nettoyés, et pas plus de travail est nécessaire. Vous faites cela en appelant GC.SuppressFinalize() dans le Dispose() méthode:
```
public void Dispose()
{
   Dispose(true); //I am calling you from Dispose, it's safe
   GC.SuppressFinalize(this); //Hey, GC: don't bother calling finalize later
}
```
Maintenant que l'utilisateur a appelé Dispose(), nous avons:
- libéré des ressources non managées
- libéré ressources gérées
Il n'y a pas de point dans le GC de l'exécution de l'outil de finalisation, tout est pris en charge.

Pourrais-je ne pas utiliser Finaliser pour le nettoyage de ressources non managées?

La documentation pour de l'Objet.Finaliser dit:

La méthode Finalize est utilisé pour effectuer des opérations de nettoyage sur les ressources non managées détenus par l'objet en cours avant que l'objet est détruit.

Mais la documentation MSDN dit aussi, pour IDisposable.Jetez:

Effectue des tâches définies par l'application associée à la libération ou à la redéfinition des ressources non managées.

Alors, qui est-il? Lequel est le lieu pour moi de nettoyage de ressources non managées? La réponse est:

C'est votre choix! Mais choisir Dispose.

Vous avez certainement pu le lieu de votre non géré nettoyage dans le finaliseur:
```
~MyObject()
{
   //Free unmanaged resources
   Win32.DestroyHandle(this.CursorFileBitmapIconServiceHandle);

   //A C# destructor automatically calls the destructor of its base class.
}
```
Le problème avec cela est que vous n'avez aucune idée de quand le garbage collector se déplacer à la finalisation de votre objet. Votre géré par les nations unies, onu-nécessaire, non utilisés natif de ressources va rester jusqu'à ce que le garbage collector finalement s'exécute. Puis il va appeler votre méthode finalizer, à nettoyer les ressources non managées. La documentation de Objet.Finaliser points: les

Le moment exact où le finaliseur exécute n'est pas défini. Pour assurer déterministe de dégager des ressources pour les instances de votre classe, de mettre en œuvre un Près méthode ou de fournir un IDisposable.Jetez mise en œuvre.

C'est la vertu de l'aide Dispose pour le nettoyage de ressources non managées; vous faire connaître et de contrôle, lorsque des ressources non managées sont nettoyées. Leur destruction est "déterministe".

Pour répondre à votre question initiale: Pourquoi ne pas libérer de la mémoire maintenant, plutôt que lorsque le GC décide de le faire? J'ai un logiciel de reconnaissance faciale qui besoins pour se débarrasser de 530 MO d'images internes maintenant, car elles ne sont plus nécessaires. Quand on n'a pas: la machine broie à une permutation de s'arrêter.

Bonus De Lecture

Pour n'importe qui qui aime le style de cette réponse (explication de l' pourquoi, de sorte que le comment devient évident), je vous conseille de lire le Chapitre Un de Ne de la Boîte de COM Essentiel:
- Lien Direct: Chapitre 1 échantillon par Pearson Publishing
- aimant: 84bf0b960936d677190a2be355858e80ef7542c0
En 35 pages, il explique les problèmes de l'utilisation des objets binaires, et invente COM devant vos yeux. Une fois que vous vous rendez compte de la pourquoi de COM, le restant de 300 pages sont évidentes, et juste détail de Microsoft de la mise en œuvre.

Je pense que chaque programmeur qui a déjà fait affaire avec des objets ou des COM devrait, à tout le moins, de lire le premier chapitre. C'est la meilleure explication de quoi que ce soit jamais.

Bonus Supplémentaire De Lecture

Quand tout ce que vous savez est faux par Eric Lippert

Il est donc très difficile d'écrire un bon outil de finalisation,
et le meilleur conseil que je puisse vous donner est de ne pas essayer.
- Ce qu'il manque, à partir de votre description est une définition de ce qu'est une ressource non managée est.
- Sauf en réalité, vous ne voulez à mettre en œuvre un finaliseur seulement dans des conditions très soigneusement contrôlée. Il y a des problèmes de performances avec les finaliseurs que la plupart des hypothèses, vous pouvez normalement faire au sujet de l'état ne sont pas valides.
- Votre dispose(bool disposing) (c'est la signature typique) devrait en fait encapsuler TOUS de votre nettoyage de la logique et de deux Dispose() et de finaliser (si vous implémentez un) devrait l'appeler avec la valeur appropriée pour l'élimination de paramètre.
- Vous pouvez faire un meilleur - vous avez besoin d'ajouter un appel à la GC.SuppressFinalize() en Débarrasser.
- "Si vous avez trouvé dans le Microsoft .NET Framework, c'est réussi." - afin que nous puissions décider quelles ressources sont gérés en fonction de si ils ont été oints par Microsoft. Il sonne comme une idée rassurante, mais il ne me donne pas la technique de la confiance! 🙂
- Peut-être aussi envisager de la classe dérivée exemple.. vous devriez faire: try { ..dérivé de nettoyage.. } finally { base.Dispose(disposing); }
- j'ai ajouté un héritage à partir d'un objet qui a déjà Disposer exemple, pour meandmycode
- Earwicker: C'est vrai. Microsoft serait l'amour pour vous d'arrêter d'utiliser Win32 complètement, et le bâton de bien abstractable, portable, appareil indépendant .NET Framework appels. Si vous voulez aller fouiner dans le système d'exploitation en dessous, parce que vous pense vous savez ce que l'OS est en cours d'exécution: vous prenez votre vie en mains propres. Pas tous les .NET application est en cours d'exécution sur Windows ou sur un bureau.
- Dans votre exemple, vous avez ce.databaseConnection = null; pour supprimer toute référence à un objet supprimé. Cependant, vous ne pouvez pas faire cela si vous avez déclaré databaseConnection en readonly. Personnellement, j'aime utiliser en lecture seule lecture seule des objets.
- Il ne peut pas vraiment être en lecture seule. Quelqu'un l'a créé, quelqu'un a jeter
- Boyd: je ne comprends pas ce que tu veux dire. Je fais référence à la C# readonly modificateur. Si votre databaseConnection champ a été déclarée en lecture seule et initialisé dans un constructeur, vous pourriez ne pas régler la valeur null après avoir fait les démarches en vue de son élimination. Vous pouvez certainement disposer de l'objet, je ne dis pas le contraire.
- Désolé. je vois ce que tu veux dire. je pensais que readonly signifiait une propriété a été readonly. je vois maintenant qu'un readonly champ n'est surtout readonly. La plupart readonly: légèrement non-readonly. Si vous souhaitez faire un champ readonly, alors je suppose que vous devrez trouver votre propre méthode pour vous protéger d'disposé des objets. Personnellement, je voudrais utiliser une propriété en lecture seule, plutôt que d'un readonly champ.
- C'est une bonne réponse, mais je peux préciser quelque chose? Si vous utilisez le GC.SuppressFinalize(ce); ai-je raison de penser que vous n'avez pas besoin de faire le check-in dispose(bool disposing) appel? Parce que une fois que vous avez supprimé le Finaliser, vous savez que vous n'allez en Jeter une fois? Par conséquent, vous pouvez définir un ReallyDisposeMe() appelée par les deux d'en Disposer et de Finaliser, en sachant que s'Aliéner a été appelé le finaliseur est ne va jamais y arriver?
- Boyd, grande réponse, question rapide: Dans votre dernière Disposer exemple vous incluez un GC.SuppressFinalize(ce); mais vous avez abandonné l'appel à la base.Disposer. L'ordre dans lequel vous appeler les deux de ces question?Je suppose qu'il doit être un bloc try avec dispose(true) et la suppression puis la enfin????
- La seule façon GC.SuppressFinalize(this) serait appelé si la personne à l'aide de votre objet en fait appelé Dispose();. Si ils n'ont pas le GC va encore venir (puisque nous emportait Finaliser) appel Dispose(false); de Sorte que vous toujours vérifier la IsItSafeToFreeManagedObjects paramètre Dispose(boolean). Si vous n'avez pas pris la peine de remplacer l'outil de finalisation, afin de Disposer d'appel dans le cas où l'utilisateur a oublié), puis non: vous n'auriez pas à vous soucier des objets gérés de ne plus être là.
- Vous n'avez qu'à appeler base.Dispose() si votre objet descend d'un objet qui implémente IDisposable. Par exemple, si votre objet descend de System.Object puis il y a n'est pas tout base.Dispose() pour vous appeler! j'ai seulement mentionné les base.Dispose() que d'un côté "Note" (Avis il est cité, fond gris, texte). Il a été conçu comme un rappel, une note, un "n'oubliez pas de chose". Il ne s'applique pas dans tous les cas - ne peut donc pas être une règle. Vous pouvez/devez seulement appeler base.Dispose() si il y a est un base.Dispose().
- Il est possible pour le système de décider d'un objet est admissible pour la finalisation tandis qu'une résurrection de suivi de la faiblesse de référence existe, et que la faiblesse de référence pour être transformée en une forte référence à l'appel de Disposer de l'objet avant ou après le finaliseur effectivement exécuté. Il serait mal pour une classe de faire une telle chose, mais les classes " doit disposer de la logique pour s'assurer de disposer de code est exécuté qu'une seule fois, indépendamment de ce que l'extérieur de code ne. Notez que Microsoft schéma est un peu déficient à cet égard.
- Depuis le développeur doit appeler Dispose sur un objet si elle met en œuvre IDisposable, puis l'faiblement objet référencé déjà a déjà été "éliminés". La résurrection de l'objet et de l'appel de Dispose est tout aussi incorrect que d'essayer d'appeler Dispose deux fois dos à dos. Un objet peut essayer de se défendre contre de tels abus. Un objet peut essayez aussi de la défendre contre les abus où l'appelant à ne pas faire appel Dispose. Mais si vous allez intentionnellement de ne pas appeler Dispose, alors vous êtes maintenant dans un monde où vous devez creuser dans le sans-papiers internes de la façon dont une classe prend en charge le nettoyage.
- Boyd: Bien que le code ne doit pas créer de la résurrection de suivi des références faibles sans une bonne raison, il serait possible pour le code qui a une telle référence et récupère sa propriété Cible à ressusciter un objet dont le finaliseur avait été mis en file d'attente, sans se rendre compte que l'objet n'était jamais allé hors de portée. C'est assez bon marché pour protéger code de nettoyage contre la double invocation (il suffit d'utiliser Interloqué.L'échange ou Contrefil.CompareExchange sur un drapeau variable) donc, je ne vois pas de raison de ne pas le faire en tant que pratique courante.
- La seule raison de ne pas le faire, c'est qu'il est difficile de faire le bien.
- Boyd: "si ((Threading.Interloqué.De change(StartedDisposing, 1) == 0) // ne jetez logique". Où est la difficulté? Si une classe de mélange gérés et non gérés, les ressources, les choses pourraient être plus compliquées, mais la solution c'est de ne pas mélanger gérés et non gérés ressources dans la même classe, au lieu de mettre les ressources non managées dans leur propre classe afin qu'ils puissent être utilisés comme des ressources gérées.
- La difficulté est que je n'ai pas la syntaxe au bout de mes doigts, et je pourrais venir avec quelque chose de différent.
- C'est une excellente réponse, mais je pense qu'il serait cependant bénéficier d'un dernier exemple de code pour un cas standard, et pour un cas où la classe dérive d'une baseclass qui implémente déjà Disposer. e.g avoir lu ici (msdn.microsoft.com/en-us/library/aa720161%28v=vs.71%29.aspx) et j'ai obtenu confus au sujet de ce que je dois faire quand dérivant de la classe qui implémente déjà Disposer (hé, je suis nouveau à cela).
- et les autres: en Général, je ne voudrais pas ennuyer définition de références à null. Tout d'abord, cela signifie que vous ne pouvez pas rendre readonly, et d'autre part, vous devez faire très moche !=null de contrôle (comme dans l'exemple de code). Vous pourriez avoir un drapeau disposed, mais il est plus facile de ne pas poser de question. L' .NET GC est assez agressif qu'une référence à un champ x ne sera plus compté "utilisé" par le temps qu'il passe la x.Dispose() ligne.
- Microsoft a également dit que votre objet doit être capable de tolérer l'utilisateur appelant Dispose plus d'une fois. Si vous n'avez pas le drapeau qui disposent déjà arrivé (en quelque sorte) alors vous allez être par inadvertance (et à tort), l'appel d'Éliminer plus d'une fois sur les objets vous utilisation.
- Mais, à son tour, chacun de ces objets ne devrait tolérer de Disposer d'être appelé plus d'une fois. Ça dépend de combien vous leur faire confiance 🙂
- Juste parce qu'un objet doit être en mesure de tolérer d'être mal utilisé ne signifie pas qu'il est juste de faire.
- Corrigez-moi si je me trompe, mais votre commentaire que vous êtes instantanément, libérant ainsi le réussi de la mémoire (les balles à droite sur le "Bonus de Lecture" de la section) avec ce motif est en fait incorrect. Vous avez non seulement les objets de sorte qu'ils seront nettoyés, la prochaine fois que le GC s'exécute, mais appelant simplement Disposer sur un objet n'a pas de libérer la mémoire pour ces ressources gérées.
- Vous êtes de droite. L'appel de Dispose sur un objet de ne pas libérer l'objet (même s'il peut libérer de la mémoire de l'objet est l'aide). je voudrais modifier le libellé; mais je ne peux pas penser à quelque chose pour le changer pour qui n'est pas extraordinairement pédant.
- serait simple si tous les développeurs toujours, il a appelé quand ils ont été fait avec l'objet, et appelé seulement une fois par objet. Mais nous avons à passer 90% du code de sauver leur cul!
- Boyd: En Effet. Merci de faire cette écriture up. VS' analyse de code m'a dit que mon Éliminer code était faux, mais je n'étais pas capable de le fixer jusqu'à ce que j'ai lu votre réponse.
- Devrait protected void Dispose(Boolean freeManagedObjectsAlso) normalement être déclaré comme virtual si nous mettons en place une classe de base? J'ai remarqué que dans la réponse ci-dessous, leur Dispose(Boolean) est virtuel.
- Aussi une autre chose: Quand je déclare dtor en tant que public, je vois une erreur de compilateur: "Ce modificateur" public " n'est pas valide pour cet article."
- Lien vers le Chapitre 1 de COM Essentiel: ptgmedia.pearsoncmg.com/images/0201634465/samplechapter/...
- +1 Grand récit! Sauf que vous pouvez faire mieux que le motif officiel!
- J'ai une petite question,: public ~Monobjet() { Jeter(false); }si la base de l'.Dispose(false) être appelé?
- Il pourrait être plus propre à diviser votre dispose(bool freeManaged) méthode en deux DisposeManagedResources() et DisposeUnmanagedResources() méthodes.
- Dans la deuxième page de Don de la Boîte de livre que vous avez mentionné, il utilise l'exemple d'un O(1) la mise en œuvre de l'algorithme de recherche, dont les détails sont laissés en exercice pour le lecteur". J'ai ri.
- À moins que la classe est scellé, le protected void Dispose(bool) méthode doit être faite virtuel pour permettre aux classes dérivées de la capacité de raccordement dans le disposer processus. La forme canonique de la signature de cette méthode est pour le paramètre d'être nommé disposing. C'est aussi typique que les ressources non gérées sont gérées une fois les ressources gérées.
- Aussi, vous n'avez pas à gérer le fait que Dispose() est réentrant. Vous n'avez aucun contrôle sur la façon dont de nombreuses fois, il pourrait être appelée, et elle doit jamais lancer une exception en raison du fait qu'il a été appelé plus d'une fois. Vous avez besoin de mettre en œuvre un private bool disposed drapeau et de le vérifier dans le Dispose(bool) méthode avant de faire quoi que ce soit (et le régler si vous n'réelle de faire un peu de travail.)
- Dorman: j'ai juste mis en œuvre ce modèle dans une classe abstraite, qui expose un virtuel protégé DisposeManagedResources et DisposeUnmanagedResources méthode, qui permet au client le code de déconner avec elle, mais ils veulent. L'dispose(bool) est fixe et des crochets dans ces méthodes, de sorte qu'ils ne peuvent pas "tout foutre en l'air".
- Désolé, mais cela implique que vous pouvez explicitement libre mémoire gérée. Ce n'est pas possible. Bitmap n'a qu'une méthode dispose, car c'est un GDI+ non géré ressources wrapper. La gestion de la mémoire existe jusqu'à ce qu'il est GC avais. Seulement non géré la mémoire est libérée au cours de la jeter.
- Non seulement n'implique pas que, il est dit explicitement qu'il.
- plus particulièrement, la présente déclaration, "se débarrasser de la gestion des ressources (parce que nous voulons être utile)". Il affirme à plusieurs reprises qu'une fois dispose est appelé "géré" les ressources sont libérées, ce qui n'est pas vrai. Je ne trouve pas dans l' (il est vrai que j'ai peut-être rater), où il est dit le contraire.
- Aussi, "Mais voulez-vous vraiment quitter 250 MO de mémoire juste assis là en attente pour le garbage collector, éventuellement, de les accompagner et de les libérer?" C'est exactement ce que vous faites parce que vous ne pouvez pas explicitement d'espace libre de la mémoire si c'est géré. Les Bitmaps juste arriver à stocker leurs données non géré, c'est pourquoi il a une méthode dispose.
- En fait, je vais commettre le downvote sur cette. Alors qu'une discussion informative pour Disposer, au final, il donne la mauvaise réponse à l'OPs question. Si vous avez un million de chaînes dans une liste, vous ne pouvez pas vous libérer en utilisant une méthode dispose. Vous ne pouvez pas explicitement libre de tout élément géré de cette façon.
- Techniquement, il est inexact de dire que "Le garbage collector sera finalement libre de tous les objets gérés". en Fait, le GC n'est pas obligé de s'exécuter si votre programme n'a pas l'expérience de la mémoire de la pression, de sorte qu'il est tout à fait possible avec certains (valide) GC implémentations de fuite de ressources par l'échec de l'appel Dispose - même si ces objets ont finaliseurs. Un finaliseur n'est même pas garanti à la fin du programme; l'exécution va essayer, mais certains types de fuites peuvent en fait s'avèrent être permanente. Donc, ne supposez pas qu'un outil de finalisation permettra d'éviter une fuite, et toujours utiliser using.
- C'est une bonne réponse, mais l'énoncé "Il doit être fait à un certain point, sinon ils ne seront jamais nettoyé" est faux et trompeur, car c'est ce 'finaliseurs" sont pour, pas IDisposable. IDisposable n'existe, et a été créé spécialement pour, l'introduction de déterministe de la destruction de la sémantique pour un système qui n'a pas déterministe de la destruction. Alors qu'il est documenté comme existant pour les ressources non managées (comme c'était la justification de retour en 2000-2001) il n'est pas fait à cause des ressources non managées, qu'il existe.. il existe pour les "déterministe nettoyage de toutes les ressources".
- Étant donné que, d'aussi loin que je peux dire, que Microsoft n'a jamais fait définit des termes comme "ressource non managée" (il se contente de donner quelques exemples), il est difficile de dire exactement ce que les choses sont ou ne sont pas inclus dans le terme. Si l'on décrit un objet Foo que "l'acquisition d'une ressource" lors de certains à l'extérieur de l'entité se met dans un moins-que-idéal pour Foo bénéficier, avec l'intention de rester dans cet état jusqu'à nouvel avis, et que "la libération d'une ressource" lorsqu'il donne un avis que ses services ne sont plus nécessaires, je dirais que s'inscrit IDisposable assez bien.
- Vous avez écrit: "Vous ne connaissez pas l'ordre dans lequel les deux objets sont détruits. Il est tout à fait possible que, dans votre Dispose() du code, la gestion de l'objet que vous essayez de vous débarrasser de n'est plus là". J'ai pensé que tant que mon objet contient une référence à un objet, cet objet ne sera jamais finalisé. Suis-je la corriger? Ainsi, même dans mon finaliser, aussi longtemps que ma référence n'est pas null, mon objet est toujours là?
- Donc, dois-je toujours mettre en œuvre un destructeur, même si je n'ai pas de ressources non managées? Pour moi, la réponse semble être "non". Je veux juste être sûr que peut-être il est préférable de le faire de toute façon, ou quelque chose?
- Il n'y a pas une telle chose comme un destructeur en C#. Tu veux dire avez-vous besoin pour mettre en œuvre un finaliseur. Vous n'avez même pas besoin de mettre en œuvre .Dispose ou un finaliseur si vous n'avez pas les ressources non managées. Vous n'avez même pas besoin de mettre en œuvre un finaliseur même si vous ne ont des ressources non managées - il n'est là que pour aller au-dessus et au-delà pour attraper le développeur qui a foiré. Si vous avez des ressources non managées, vous avez seulement besoin de mettre en œuvre des certains méthode (par exemple,Dispose) pour nettoyer ces ressources. La personne à l'aide de votre classe est obligatoire pour l'appeler quand il est fait à l'aide.
- Merci Ian, c'est une de mes préférées des réponses sur LE! J'ai lié dans mon récent billet de blog sur dépendances qui implémentent l'interface IDisposable.
- "Pourquoi ne pas libérer de la mémoire maintenant, plutôt que lorsque le GC décide de le faire?" Le réglage de la valeur null n'est pas gratuit. Seulement GC pouvez libérer de la mémoire. Il est effrayant que vous ne le savez pas, parce que tout ce que vous écrivez sens.
- Si vous disposez d'un ensemble d'instances qui sont tous inaccessible de "références racine", ces objets sont elegible pour la collecte par le GC. Même s'ils ont des références parmi eux. Donc, il y a des cas, par exemple de dépendances circulaires, lorsqu'un objet est collecté après les objets qu'il désigne. Dispose() ou le finaliseur peut être appelé à ce stade.
- J'ai créé un blog qui montre un dernier exemple de code, basé sur la réponse donnée ici. J'espère que c'est utile à quelqu'un: inaspiralarray.blogspot.com/2013/04/...
- La finalisation est pas ordonné, oui. Sinon, dépendances circulaires serait un problème. Toutefois, cela ne signifie pas que des objets finalisables vous avez encore une référence à sont collectées. Ils ne sont pas aussi longtemps que vous faites référence à eux. En d'autres termes, vous avez encore une référence à un objet qui est valable dans un sens. La seule considération est que cette finaliseur de l'objet pourrait avoir été appelé déjà. Voir cet article pour plus d'info: blogs.msdn.microsoft.com/cbrumme/2004/02/20/finalization
- Comme le des lignes directrices de Microsoft unis, les utilisateurs s'attendent qu'un appel à Disposer ne déclenche pas d'exception. Donc, je voudrais éviter d'utiliser un try-finally bloc autour de dispose(bool) comme il n'est pas destiné à jeter. Oui, vous ne savez jamais ce qui pourrait arriver avec unmanaged code externe, mais pour ce faire, vous voudrez probablement aller le try-finally bloc vers le bas à la méthode dispose(bool) aussi près que possible des ressources non managées de presse.
- J'ai raté la partie où vous avez répondu "qu'est Ce qu'une ressource non managée?".
- Enfin() je peux dire que j'ai vraiment comprendre pourquoi je fais tout ~ce(:-), l'Une des meilleures réponses à 10x bro.
- Vous savez, c'est une grande réponse lorsque, après lecture, vous avec enthousiasme revenir en arrière jusqu'à voter juste pour voir ce que vous avez déjà.
- gist.github.com/iamdroppy/ddef0a8b1cee23f0d47d35abd9828a10 @Sinjai
- Ce vraiment une bonne réponse! J'apprécie vraiment la façon dont il vous guide à travers l'explication de la même façon, on allait à pied à travers leurs propres processus de pensée. Il n'a pas vider tout à vous tous à la fois, au lieu de choisir de se concentrer sur la personne des raisons pour cela. Je jouais avec mon propre Jetable mise en œuvre essayant de penser à tout cela à travers et j'ai encore raté certaines choses que j'ai maintenant pris grâce à ce post. Tout simplement excellent. Tout simplement, si MS avait un écrivain comme vous (tous) pour leur documentation, nous serions tous d'excellents développeurs.
- Je suis en train d'en vertu de la nécessité pour la troisième méthode. Si databaseConnection objet n'existe plus (parce que GC déjà repris que vers le haut) puis la façon, la condition this.databaseConnection != null évaluer à vrai? Dans ce cas, il n'exécutez jamais this.databaseConnection.Dispose() et plantage ne se produit pas.. Pourriez-vous me dire qu'est-ce qui me manque ici.
- Le databaseConnection continuera d'exister lorsque l'utilisateur appelle Dispose, parce que votre objet a toujours une référence. Le garbage collector ne pas collecter des objets pendant qu'ils ont encore des références.
- Merci @IanBoyd pour la clarification. OK, Donc quand l'utilisateur appelle Dispose, il n'y a aucun moyen de GC déjà recueilli 'databaseConnection', alors comment se fait il y aura un crash lors de la prochaine ligne de this.databaseConnection.Dispose() est exécuté ? Ce Crash a été la principale raison pour laquelle nous avons introduit la troisième méthode..Droit?
- C'est parce que nous lancer le bug potentiel lorsque nous avons décidé d'appeler Dispose(bool) à partir de l'outil de finalisation. Si votre objet est en cours de finalisation, puis tout ce que vous peut-être disparu. Mais quand le utilisateur appels en Disposer, nous savons que tout doit être bon, parce que le CLR ne serait pas finalisé tout ce que nous encore de référence. Une fois notre objet n'est plus référencé, toutes les références que nous avons tenues sont potentiellement disparu.
- Il est plus facile à mettre en œuvre en Disposer correctement si vous suivez ces conseils: lien Il supprime l'compliqué cas où vous avez tous les deux gérés et non gérés ressources en faisant des choix autour de finaliseurs plus facile à gérer
- Boyd Grande Réponse! Merci Beaucoup!
InformationsquelleAutor
61

IDisposable est souvent utilisé pour exploiter les using déclaration et de profiter d'un moyen facile de le faire déterministe de nettoyage d'objets gérés.
```
public class LoggingContext : IDisposable {
    public Finicky(string name) {
        Log.Write("Entering Log Context {0}", name);
        Log.Indent();
    }
    public void Dispose() {
        Log.Outdent();
    }

    public static void Main() {
        Log.Write("Some initial stuff.");
        try {
            using(new LoggingContext()) {
                Log.Write("Some stuff inside the context.");
                throw new Exception();
            }
        } catch {
            Log.Write("Man, that was a heavy exception caught from inside a child logging context!");
        } finally {
            Log.Write("Some final stuff.");
        }
    }
}
```
- Je voudrais que, personnellement, mais ça n'a pas vraiment jive avec le cadre des lignes directrices de conception.
- Je pense qu'il serait bon de conception, car elle permet de facile déterministe étendues et l'étendue de construction et de nettoyage, en particulier lorsque mélangés à l'exception de manutention, de verrouillage, et non géré-ressource à l'aide de blocs de façon complexe. Le langage de cette première caractéristique de la classe.
- Il n'a pas exactement suivi les règles spécifiées dans le FDG, mais il est certainement un bon usage de la répétition comme il est nécessaire pour être utilisé par l' "à l'aide de déclaration".
- Tant que Journal.Hausser n'est pas à jeter, il n'y a absolument rien de mal à cela.
- Les différentes réponses aux Est-il abusif d'utiliser IDisposable et de “l'aide”, comme un moyen pour obtenir de “l'étendue comportement” d'exception de sécurité? aller dans un peu plus en détail sur les raisons de différentes personnes aiment/j'aime pas cette technique. C'est quelque peu controversé.
- Qu'est-ce exactement est "déterministe de nettoyage de la gestion des ressources" ici? Cette utilisation de l'Dispose() ne nettoie rien. Il utilise simplement une méthode statique. Il n'y a pas .NET objet libéré à tous.
InformationsquelleAutor yfeldblum
43

Le but du modèle dispose est de fournir un mécanisme pour nettoyer à la fois réussi et les ressources non managées et lorsque cela se produit dépend de la façon dont la méthode dispose est appelé. Dans votre exemple, l'utilisation de Jeter n'est pas en train de faire tout ce qui est lié à disposer, depuis la compensation d'une liste n'a pas d'impact sur la collection en cours de cession. De même, les appels à définir les variables à null également ne pas avoir d'impact sur la GC.

Vous pouvez prendre un coup d'oeil à ce l'article pour plus de détails sur la façon de mettre en œuvre le modèle dispose, mais fondamentalement, ça ressemble à ça:
```
public class SimpleCleanup : IDisposable
{
    //some fields that require cleanup
    private SafeHandle handle;
    private bool disposed = false; //to detect redundant calls

    public SimpleCleanup()
    {
        this.handle = /*...*/;
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                //Dispose managed resources.
                if (handle != null)
                {
                    handle.Dispose();
                }
            }

            //Dispose unmanaged managed resources.

            disposed = true;
        }
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
}
```
La méthode qui est le plus important ici est l'dispose(bool), qui en réalité s'exécute dans deux cas différents:
- élimination == true: la méthode a été appelée directement ou indirectement par un code d'utilisateur. Gérés et non gérés, les ressources peuvent être éliminés.
- élimination == false: la méthode a été appelée par le moteur d'exécution de l'intérieur de l'outil de finalisation, et vous ne devriez pas faire référence à d'autres objets. Seulement les ressources non managées peuvent être éliminés.
Le problème avec simplement laisser le GC prendre soin de faire le nettoyage, c'est que vous n'avez pas de réel contrôle sur le moment où le GC exécuter un cycle de collecte de données (vous pouvez appeler GC.Collect(), mais vous ne devriez vraiment pas), alors que les ressources peuvent rester plus longtemps que nécessaire. Rappelez-vous, en appelant Dispose() n'est pas réellement de causer un cycle de collecte ou de quelque façon que provoquer la GC pour les collecter, de les gratuit de l'objet; il fournit simplement le moyen de deterministicly nettoyage des ressources utilisées et de dire la GC que ce nettoyage a déjà été effectué.

Le point de l'ensemble de IDisposable et le modèle dispose n'est pas immédiatement libérer de la mémoire. Le seul moment où un appel à Disposer va en fait de même avoir une chance de faire immédiatement la libération de la mémoire, c'est quand il est de la manipulation de l'élimination == false scénario et la manipulation des ressources non managées. Pour le code managé, la mémoire n'est pas réellement être récupéré jusqu'à ce que le GC exécute un cycle de collecte, de laquelle vous avez vraiment n'avez aucun contrôle sur (autres que l'appel d'GC.Collect(), qui comme je l'ai déjà mentionné, c'est pas une bonne idée).

Votre scénario n'est pas vraiment valable depuis les chaînes de dans .NET ne pas utiliser n'importe quel unamanged ressources et de ne pas mettre en œuvre IDisposable, il n'y a aucun moyen de les forcer à être "nettoyé."
- N'avez-vous pas oublier de mettre en œuvre finaliseur?
- Non, il est à l'aide d'un SafeHandle. Pas besoin d'un destructeur.
- +1 pour ajouter le filet de sécurité pour les appels multiples à Éliminer(). La spécification dit plusieurs appels doivent être sûrs. Trop de Microsoft classes ne parviennent pas à mettre en œuvre, et vous obtenez l'ennuyeux le ObjectDisposedException.
- Mais dispose(bool disposing) est votre propre méthode sur votre SimpleCleanup classe et ne sera jamais appelée par le framework. Comme vous ne l'appeler avec un "vrai" comme un paramètre "l'élimination" ne sera jamais faux. Votre code est très similaire à la MSDN exemple pour IDisposable, mais manque le finaliseur, comme @Budda souligné, qui est l'endroit où l'appel à l'élimination = false viendrait.
InformationsquelleAutor Scott Dorman
19

Il ne devrait plus les appels à un objet de méthodes d'Aliéner a été appelée sur elle (même si un objet doit tolérer appelle en outre à Disposition). Par conséquent, l'exemple de la question est stupide. Si Disposer est appelée, l'objet lui-même peut être mis au rebut. Ainsi l'utilisateur doit juste jeter toutes les références à cet objet entier (mis à null) et de tous les objets liés à l'interne il sera automatiquement nettoyé.

Comme pour la question générale sur les sites gérés et non gérés, et la discussion dans d'autres réponses, je pense que la réponse à cette question doit commencer par une définition d'une ressource non managée.

Ce que cela revient à dire qu'il y a une fonction que vous pouvez appeler pour mettre le système dans un état, et il y a une autre fonction que vous pouvez appeler pour le ramener à sortir de cet état. Maintenant, dans le typique exemple, le premier peut-être une fonction qui renvoie un descripteur de fichier, et le second pourrait être un appel à CloseHandle.

Mais - et c'est la clé, ils pourraient être n'importe quelle paire de fonctions. On construit un etat, l'autre l'arrache. Si l'état a été construit, mais pas déchiré vers le bas encore, puis une instance de la ressource existe. Vous devez prendre des dispositions pour le démontage pour arriver au bon moment - la ressource n'est pas géré par le CLR. La seule automatiquement géré type de ressource est la mémoire. Il en existe deux types: le GC, et la pile. Types de valeur sont gérés par la pile (ou par baladait à l'intérieur de types de référence), et les types de référence sont gérés par le GC.

Ces fonctions peuvent provoquer des modifications de l'état qui peuvent être librement entrelacés, ou peut-être besoin d'être parfaitement imbriqués. Les changements d'état peuvent être thread-safe, ou ils ne pourraient pas.

Regardez l'exemple dans la Justice de la question. Les modifications dans le fichier Journal de l'indentation doit être parfaitement imbriqués, ou tout va mal. En outre, ils sont peu susceptibles d'être thread-safe.

Il est possible de faire du stop avec le garbage collector pour obtenir votre des ressources non managées nettoyé. Mais seulement si le changement d'état des fonctions sont thread-safe et deux états peuvent avoir des durées de vie qui se chevauchent en aucune façon. Alors que la Justice l'exemple d'une ressource ne doit PAS avoir un finaliseur! Il n'aurait tout simplement pas aider tout le monde.

Pour ces types de ressources, vous pouvez simplement mettre en œuvre IDisposable, sans un finaliseur. Le finalizer est absolument facultatif - il doit l'être. C'est l'estomper ou même pas mentionné dans de nombreux ouvrages.

Ensuite, vous devez utiliser le using instruction pour avoir une chance de s'assurer que Dispose est appelé. C'est pratiquement comme se baladait avec la pile (donc comme finalizer est à la GC, using est à la pile).

La partie manquante est que vous avez à écrire manuellement Éliminer et de faire appel sur vos champs et de votre classe de base. C++/CLI, les programmeurs ne pas avoir à le faire. Le compilateur écrit pour eux dans la plupart des cas.

Il y a une alternative, que je préfère pour les états qui s'emboîtent parfaitement et ne sont pas thread-safe (en dehors de toute autre chose, en évitant IDisposable vous épargne le problème d'avoir une dispute avec quelqu'un qui ne peut pas résister à l'ajout d'un finaliseur à chaque classe qui implémente IDisposable).

Au lieu d'écrire une classe, vous écrivez une fonction. La fonction accepte un délégué pour rappel:
```
public static void Indented(this Log log, Action action)
{
    log.Indent();
    try
    {
        action();
    }
    finally
    {
        log.Outdent();
    }
}
```
Et puis un exemple simple serait:
```
Log.Write("Message at the top");
Log.Indented(() =>
{
    Log.Write("And this is indented");

    Log.Indented(() =>
    {
        Log.Write("This is even more indented");
    });
});
Log.Write("Back at the outermost level again");
```
Le lambda étant passé en sert comme d'un bloc de code, donc c'est comme vous faire votre propre structure de contrôle pour servir le même but que using, sauf que vous n'avez plus aucun danger de l'appelant en abuser. Il n'ya aucun moyen qu'ils peuvent échouer pour nettoyer la ressource.

Cette technique est moins utile si la ressource est le genre qui peut avoir cumul des durées de vie, parce qu'alors, vous voulez être en mesure de construire des ressources A, puis B de ressource, puis de les tuer ressource et puis plus tard, tuer des ressources B. Vous ne pouvez pas faire cela si vous avez forcé à l'utilisateur de parfaitement nid comme ça. Mais alors vous devez utiliser IDisposable (mais toujours sans un finaliseur, sauf si vous avez mis en œuvre threadsafety, qui n'est pas gratuit).
- re: "Il ne devrait plus les appels à un objet de méthodes d'Aliéner a été appelée sur elle". "Devrait" est le mot clé. Si vous avez asynchrone les actions en cours, ils peuvent venir après votre objet a été disposé. Provoquant ObjectDisposedException.
- La vôtre semble être la seule réponse autre que la mienne qui se fonde sur l'idée que les ressources non managées encapsuler état que le GC ne pas comprendre. Un aspect clé d'une ressource non managée, cependant, est qu'une ou plusieurs entités dont l'état pourrait avoir besoin de nettoyer son état peut continuer à exister même si l'objet qui est "propriétaire" de la ressource n'est pas. Comment aimez-vous ma définition? Assez similaire, mais je pense qu'il fait de la "ressource" un peu plus nom-ish (c'est le "contrat" par l'extérieur de l'objet à modifier son comportement, en échange d'une notification lorsque ses services ne sont plus nécessaires)
- si vous êtes intéressé, j'ai écrit le post suivant un couple de jours après, j'ai écrit la réponse ci-dessus: smellegantcode.wordpress.com/2009/02/13/...
- Article intéressant, bien que je ne peux penser à au moins un type de ressource non managée vous n'avez pas vraiment de couverture: abonnements à des événements de longue durée de vie des objets. Les abonnements d'événements sont fongibles, mais même si la mémoire illimité échec à disposer d'eux pourrait être coûteux. Par exemple, un agent recenseur pour une collection qui permet de modifier au cours de l'énumération pourriez avoir besoin pour vous abonner à des notifications de mise à jour de la collection, et une collection peut être mis à jour de nombreuses fois dans sa durée de vie. Si les agents recenseurs sont abandonnés sans se désabonner...
- ...la liste des abonnés reçois de plus en plus gros. Même si la mémoire infinie, le temps de simplement traiter chaque demande d'abonnement pourrait croître sans limite. Je ne pense pas que votre modèle s'adapte très bien à ce modèle, car il n'est pas clair ce que c'est que d'être "affecté". Dans un certain sens, les abonnements d'événements sont encore plus fongibles de mémoire non managée. D'autre part, une inscription à l'événement est admissible en tant que "quelque chose d'un objet a demandé à une autre entité à le faire en son nom".
- La paire d'opérations enter et exit est la base de la façon dont je pense à une ressource. Abonnement/désabonnement sur les événements s'inscrivent dans que sans difficulté. En termes de orthogonale/fongibles caractéristiques, il est pratiquement impossible à distinguer d'une fuite de mémoire. (Ceci n'est pas surprenant puisque l'abonnement est juste d'ajouter des objets à une liste.)
- Ce qui fait événement abonnements différent de toutes les autres ressources que vous décrivez, c'est que même si la piscine de "bits" est infini, on peut pointer les bits encapsulé par une ressource et de savoir qu'il a l'usage exclusif d'entre eux. En revanche, un événement abonnement ne prend pas en faire un objet identifiable pas disponible pour autre chose. Il va augmenter la quantité de mémoire consommée par la liste d'abonnement, et la quantité de temps nécessaire pour le traiter, mais il n'y a pas discret "chose" qui le rend indisponible pour quelque chose d'autre.
- Comme pour "entrer" et "sortir", ceux-ci sont souvent utilisés dans les cas où la "saisie" implique l'utilisation exclusive de quelque chose jusqu'à ce que le correspondant de "sortie". Même si l'on est à l'aide d'une entrée/sortie de paradigme avec quelque chose comme des balises HTML dans un cours d'eau, c'est plus propre d'avoir la méthode de factorisation qui entre retourner un objet qui encapsule le flux et sortie directe qui, plutôt que de continuer avec la sortie du flux.
- dépend... si l'objectif est que toutes les sorties à travers le enveloppés contexte?
- Pour quelque chose d'un document HTML, si quoi que ce soit envoyés entre une balise d'ouverture et la balise de fermeture sera une partie de cet élément, il serait plus propre d'exiger que rien ne soit envoyé au ruisseau sauf via l'objet de l'encapsulation de l'étiquette, que d'avoir l'étiquette de l'objet de modifier le sens des choses envoyé dans le flux. Il peut ne pas toujours être possible d'appliquer un tel comportement, mais en ayant le tag objet de prendre en charge le flux et nourrir le contenu de la balise par le biais de cet objet va permettre de la possibilité de la modification d'appliquer le bon comportement ou...
- ...de changer le tag de l'objet afin qu'il les tampons de tout jusqu'à ce qu'il est fermé, puis écrit la balise d'ouverture, le contenu et la balise de fermeture comme une unité [comportement qui pourrait être sémantiquement plus propre que l'envoi de la balise d'ouverture au moment de sa création, mais qui aurait besoin de plus de mémoire].
InformationsquelleAutor Daniel Earwicker

Scénarios-je faire usage de IDisposable: nettoyer les ressources non managées, désabonnez-vous pour des événements, des liens étroits

Le langage que j'utilise pour la mise en œuvre de IDisposable (pas thread-safe):

class MyClass : IDisposable {
    //...

    #region IDisposable Members and Helpers
    private bool disposed = false;

    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    private void Dispose(bool disposing) {
        if (!this.disposed) {
            if (disposing) {
                //cleanup code goes here
            }
            disposed = true;
        }
    }

    ~MyClass() {
        Dispose(false);
    }
    #endregion
}

Modèle complet explication peut être trouvée dans le msdn.microsoft.com/en-us/library/b1yfkh5e.aspx
ne devriez jamais un finaliseur inclus, sauf si vous avez les ressources non managées. Même alors, le préféré de mise en œuvre consiste à envelopper la ressource non managée dans SafeHandle.

InformationsquelleAutor olli-MSFT

11

Yep, que le code est complètement redondant et inutile, et il ne fait pas le garbage collector n'importe quoi qu'il ne serait pas faire autrement (une fois qu'une instance de MyCollection est hors de portée, ce qui est.) Surtout la .Clear() appels.

Réponse à votre edit: en quelque Sorte. Si je fais ceci:
```
public void WasteMemory()
{
    var instance = new MyCollection(); //this one has no Dispose() method
    instance.FillItWithAMillionStrings();
}

//1 million strings are in memory, but marked for reclamation by the GC
```
Il est fonctionnellement identique à ce à des fins de gestion de la mémoire:
```
public void WasteMemory()
{
    var instance = new MyCollection(); //this one has your Dispose()
    instance.FillItWithAMillionStrings();
    instance.Dispose();
}

//1 million strings are in memory, but marked for reclamation by the GC
```
Si vous avez vraiment vraiment vraiment besoin de libérer de la mémoire, ce même instant, l'appel GC.Collect(). Il n'y a pas de raison de le faire ici. La mémoire sera libérée lorsque cela est nécessaire.
- re: "La mémoire sera libérée lorsque cela est nécessaire." Dites plutôt: "lorsque GC décide qu'il est nécessaire." Vous pouvez voir les problèmes de performances du système avant de GC décide que la mémoire est vraiment nécessaire. Libérant jusqu' maintenant peut-être pas indispensable, mais peut être utile.
- Il y a quelques cas particuliers dans lesquels micropression des références au sein d'une collection peut accélérer la collecte des ordures des éléments mentionnés ainsi. Par exemple, si un grand tableau est créé et rempli de références à petits nouvellement créé éléments, mais il n'est pas nécessaire pour très longtemps après que, l'abandon de la pile peut provoquer ces éléments de façon à être conservés jusqu'à la prochaine Niveau 2 GC, tandis que la réduction à zéro tout d'abord peut faire des éléments admissibles pour le prochain niveau 0 ou de niveau 1 GC. Pour être sûr, avoir de gros objets éphémères sur le Tas d'Objets Volumineux est dégueulasse de toute façon (je n'aime pas le design), mais...
- ...mise à zéro de tels tableaux, avant de les abandonner mon parfois diminuer l'impact GC.
InformationsquelleAutor mqp
11

Si MyCollection va être nettoyée de toute façon, alors vous ne devriez pas avoir à jeter. Vous risqueriez juste de désabonnement de la CPU plus que nécessaire, et peut même annuler certains pré-calculées de l'analyse que le garbage collector a déjà effectué.

- Je utiliser IDisposable de faire des choses comme assurer les threads sont éliminés correctement, avec des ressources non managées.

MODIFIER En réponse à Scott commentaire:

Le seul moment où le GC mesures de performance sont touchés, c'est quand un appel [sic] GC.Collect() est faite"

Sur le plan conceptuel, la GC maintient une vue de l'objet graphique de référence, et toutes les références à partir de la pile d'images de threads. Ce segment peut être assez grande, et s'étendre sur plusieurs pages de la mémoire. Comme une optimisation, le GC cache son analyse des pages qui sont peu susceptibles de changer très souvent pour éviter une nouvelle analyse de la page inutilement. Le GC reçoit un avis du noyau lorsque les données d'une page de changements, de sorte qu'il sait que la page est sale et nécessite une nouvelle analyse. Si la collection est en Gen0 alors il est probable que d'autres choses dans la page sont en train de changer aussi, mais c'est moins probable dans Gen1 et Gen2. Pour l'anecdote, ces crochets ne sont pas disponibles dans Mac OS X pour l'équipe qui a porté le GC pour Mac afin d'obtenir le plug-in Silverlight de travail sur cette plate-forme.

Un autre point contre inutile disposition de ressources: imaginer une situation où un processus est en cours de déchargement. Imaginez également que le processus a été en cours d'exécution pendant un certain temps. Les Chances sont que beaucoup de mémoire de ce processus de pages ont été échangés sur le disque. À tout le moins, elles ne sont plus en L1 ou L2 cache. Dans une telle situation, il n'y a aucun point pour une application de déchargement pour échanger toutes ces données et le code des pages en mémoire de "libérer" les ressources qui vont être libérés par le système d'exploitation de toute façon lorsque le processus se termine. Cela s'applique à géré et même certaines ressources non managées. Seules les ressources garder les threads d'arrière-plan en vie doivent être éliminés, sinon le processus restera vivant.

Maintenant, lors de l'exécution normale il y éphémères sont des ressources qui doivent être nettoyés correctement (comme @fezmonkey souligne connexions de base de données, des sockets, des poignées de fenêtre) pour éviter de non managé des fuites de mémoire. Ce sont le genre de choses qui doivent être éliminés. Si vous créez une classe qui possède un thread (et par propriétaire, je veux dire qu'il a créé et qu'il est donc responsable de veiller à ce qu'il s'arrête, au moins par mon style de codage), alors que la classe la plus probable doit mettre en œuvre IDisposable et d'arracher le fil au cours de Dispose.

L' .NET framework utilise le IDisposable interface comme un signal, même avertissement, pour que les développeurs de cette classe doit être éliminés. Je ne peux pas penser à tout types dans le cadre de mettre en œuvre IDisposable (à l'exclusion explicite des implémentations d'interface) où l'immersion est facultatif.
- L'appel de Disposer est parfaitement valide, légale et encouragée. Les objets qui implémentent IDisposable généralement pour une raison. Le seul moment où le GC mesures de performance sont touchés, c'est quand un appel de la GC.Collect() est faite.
- Pour de nombreuses personnes .net classes, l'immersion est "un peu" en option, ce qui signifie que l'abandon de cas "général" ne causera pas de problèmes tant que l'on n'est pas fous, la création de nouvelles instances et de les abandonner. Par exemple, le code généré par le compilateur pour les contrôles semble créer des polices lorsque les contrôles sont instanciés et de les abandonner quand les formes sont éliminés; si l'on crée et supprime des milliers de contrôles , ce qui pourrait attacher des milliers de GDI poignées, mais dans la plupart des cas, les contrôles ne sont pas créés et détruits que beaucoup. Néanmoins, on doit toujours essayer d'éviter de telles abandon.
- Dans le cas de polices, je soupçonne que le problème est que Microsoft n'a jamais vraiment défini ce que l'entité est responsable de l'élimination de la "police" un objet affecté à un contrôle; dans certains cas, un contrôle peut partager une police avec une longue durée de vie de l'objet, afin d'avoir le contrôle de Jeter la police serait mauvais. Dans d'autres cas, une police sera affectée à un contrôle et nulle part ailleurs, donc si le contrôle ne dispose pas personne ne le fera. D'ailleurs, cette difficulté avec des polices qui auraient pu être évitées s'il y avait eu un espace non-jetables FontTemplate de la classe, puisque les contrôles ne semblent pas utiliser les ressources GDI de leur Police.
- Sur le sujet de l'option Dispose() appels, voir: stackoverflow.com/questions/913228/...
InformationsquelleAutor Drew Noakes
7

Si vous voulez supprimer dès maintenant, utilisez mémoire non managée.

Voir:
InformationsquelleAutor franckspike
6

Dans l'exemple que vous avez posté, il n'est toujours pas "libérer de la mémoire, maintenant". Toute la mémoire garbage collecté, mais il peut permettre à la mémoire pour être recueilli dans un précédent génération. Vous auriez à faire quelques tests pour être sûr.

Le Cadre des lignes Directrices de Conception sont des lignes directrices et non des règles. Ils vous disent ce que l'interface est principalement, quand l'utiliser, comment l'utiliser et quand ne pas utiliser.

J'ai lu une fois le code qui était un simple RollBack() en cas d'erreur en utilisant IDisposable. Le MiniTx de classe ci-dessous serait de vérifier un drapeau sur Dispose() et si le Commit appel n'est jamais arrivé il serait alors appel Rollback sur lui-même. Elle a ajouté une couche d'indirection faire le code d'appel est beaucoup plus facile à comprendre et à maintenir. Le résultat cherché quelque chose comme:
```
using( MiniTx tx = new MiniTx() )
{
    //code that might not work.

    tx.Commit();
} 
```
J'ai aussi vu le timing /code d'enregistrement de faire la même chose. Dans ce cas, la méthode dispose() arrêté le chronomètre et connecté que le bloc avait quitté.
```
using( LogTimer log = new LogTimer("MyCategory", "Some message") )
{
    //code to time...
}
```
Donc, ici, sont quelques exemples de mesures concrètes qui ne le font pas tout non managé des ressources de nettoyage, mais n'en a utilisé avec succès IDisposable pour créer nettoyeur de code.
- Jetez un oeil à @Daniel Earwicker l'exemple en utilisant des fonctions d'ordre supérieur. Pour l'analyse comparative, le calendrier, l'exploitation forestière, etc. Il semble beaucoup plus simple.
InformationsquelleAutor Robert Paulson
6

Je ne vais pas répéter les trucs habituels sur l'Utilisation ou de libérer géré par les nations unies de ressources, que tout a été couvert. Mais je tiens à souligner ce qui me semble une idée fausse commune.

Étant donné le code suivant
```
Public Class LargeStuff 
Implémente IDisposable 
Privé _Large comme une chaîne de caractères() 

"Certains étrange code qui signifie _Large contient maintenant plusieurs millions de longues chaînes. 

Public Sub Dispose() Implémente IDisposable.Disposer 
_Large=Rien 
End Sub 
```
Je me rends compte que les Jetables mise en œuvre ne suit pas les lignes directrices actuelles, mais j'espère que vous tous obtenez l'idée.

Maintenant, lorsque Disposer est appelé, la quantité de mémoire obtient libéré?

Réponse: Aucune.

Appeler dispose peut libérer des ressources non managées, il NE peut pas récupérer la mémoire gérée, seulement le GC peut le faire. Thats pour ne pas dire que ce n'est pas une bonne idée, en suivant le schéma ci-dessus est toujours une bonne idée en fait. Une fois Aliéner a été exécuté, il n'en est rien, l'arrêt de la GC réclamer la mémoire qui a été utilisée par _Large, même si l'instance de LargeStuff peut encore être portée. Les chaînes de _Large peut aussi être dans la génération 0, mais l'instance de LargeStuff pourrait être gen 2, donc encore une fois, la mémoire serait ré-affirmé plus tôt.

Il n'y a pas de point dans l'ajout d'un finaliser appeler la méthode dispose indiqué ci-dessus si. Cela ne fera que RETARDER la re-revendication de la mémoire pour permettre de le finaliser à exécuter.
- Si une instance de LargeStuff a été autour assez longtemps pour le faire à la Génération 2, et si _Large contient une référence à une nouvelle chaîne qui est dans la Génération 0, alors, si l'instance de LargeStuff est abandonné sans micropression hors _Large, puis de la chaîne visée par _Large seront conservés jusqu'à ce que la prochaine Gen2 collection. Réinitialisation _Large peut laisser la chaîne supprimées lors de la prochaine Gen0 collection. Dans la plupart des cas, micropression des références n'est pas utile, mais il y a des cas où il peut offrir certains avantages.
InformationsquelleAutor pipTheGeek
5

En dehors de son utilisation principale comme un moyen de contrôle de la vie de ressources système (entièrement couverts par la réponse impressionnante de Ian, bravo!), le IDisposable/à l'aide de combo peut également être utilisé pour champ d'application de la modification de l'état de la (critique) des ressources mondiales: le console, le fils, le processus, tout objet global comme un instance d'application.

J'ai écrit un article à propos de ce modèle: http://pragmateek.com/c-scope-your-global-state-changes-with-idisposable-and-the-using-statement/

Il illustre comment vous pouvez protéger certaines souvent utilisés l'état global dans un réutilisables et lisible manière: console de couleurs, actuel fil de la culture, Excel propriétés de l'objet application...

InformationsquelleAutor Pragmateek
4

Si quoi que ce soit, j'imagine que le code à moins efficace que lorsque les laissant.

L'appel de la Clear() les méthodes sont inutiles, et que le GC ne serait probablement pas faire que si les Éliminer ne l'ai pas fait...

InformationsquelleAutor Arjan Einbu
2

Il y a des choses que l' Dispose() opération dans l'exemple de code que pourrait ont un effet qui ne serait pas due à une normale GC de la MyCollection objet.

Si les objets référencés par _theList ou _theDict sont visés par d'autres objets, alors que List<> ou Dictionary<> objet ne sera pas soumis à la collection, mais soudain ont pas de contenu. Si il n'y avait pas Dispose() de l'opération, comme dans l'exemple, ces collections contiennent encore de leur contenu.

Bien sûr, si c'était la situation je dirais que c'est une fracture de la conception, je suis juste rappelé manière affectée, je suppose) que la Dispose() opération risque de ne pas être complètement redondant, selon qu'il y a d'autres utilisations de la List<> ou Dictionary<> qui ne sont pas affichés dans le fragment.
- Ils sont privés des champs, donc je pense qu'il est juste de supposer que l'OP n'est pas de donner des références pour eux.
- 1) le fragment de code est juste un exemple de code, donc je signale simplement qu'il y a peut être un effet secondaire qui est facile à oublier; 2) les champs sont souvent la cible d'un getter de la propriété/méthode - peut-être trop (lecture/définition sont considérés par certains d'être un peu un anti-pattern).
InformationsquelleAutor Michael Burr
2

Un problème avec la plupart des discussions de "ressources non managées", c'est qu'ils n'ont pas vraiment de définir le terme, mais semblent impliquer qu'il a quelque chose à faire avec du code non managé. S'il est vrai que de nombreux types de ressources non managées faire l'interface avec le code non managé, la pensée de ressources non managées dans de telles conditions n'est pas utile.

Au lieu de cela, il faut reconnaître que toutes les ressources gérées ont en commun: ils entraînent un objet à poser à l'extérieur "chose" à faire quelque chose en son nom, au détriment de certains autres "choses", et de l'autre entité acceptant de le faire jusqu'à nouvel avis. Si l'objet était abandonnée et disparaissent sans laisser de trace, rien n'aurait pu dire qu'en dehors de "chose" qu'il n'est plus nécessaire de modifier son comportement sur le nom de l'objet qui n'existait plus; par conséquent, la chose de l'utilité serait définitivement diminuée.

Une ressource non managée, puis, représente un accord par certains à l'extérieur de chose à modifier son comportement sur le nom d'un objet, qui serait inutile de nuire à l'utilité de l'extérieur "chose" si l'objet ont été abandonnés et a cessé d'exister. Une gestion de la ressource est un objet qui en est le bénéficiaire d'un tel accord, mais qui a signé jusqu'à recevoir une notification si elle est abandonnée, et qui va utiliser cette notification, pour mettre ses affaires en ordre avant qu'il soit détruit.
- Ainsi, l'OMI, la définition de l'objet non géré est clair; tous les non-GC objet.
- Objet Non Géré != Ressource Non Managée. Des choses comme les événements peuvent être mis en œuvre entièrement à l'aide d'objets gérés, mais encore constituent des ressources non managées parce que-au moins dans le cas d'objets éphémères abonnement à durée de vie longue-objets' événements-le GC ne sait rien sur la façon de les nettoyer.
InformationsquelleAutor supercat
2

IDisposable est bon pour vous désabonner de ces événements.

InformationsquelleAutor Adam Speight
2

D'abord de la définition. Pour moi non managé des ressources signifie qu'une classe qui implémente l'interface IDisposable ou quelque chose de créé avec l'utilisation des appels de dll. GC ne savent pas comment faire face à de tels objets. Si la classe a, par exemple, seuls les types de valeur, puis je ne pas considérer cette classe comme une classe avec des ressources non managées.
Pour mon code, je l'ai suivi de nouvelles pratiques:
1. Si elle est créée par moi-classe utilise des ressources non managées, alors cela signifie que je dois aussi mettre en œuvre interface IDisposable afin de nettoyer la mémoire.
2. Nettoyer les objets dès que j'ai fini d'utilisation de celui-ci.
3. Dans ma méthode dispose je itérer sur tous les IDisposable membres de la classe et de l'appel d'Aliéner.
4. Dans mon Éliminer l'appel de la méthode GC.SuppressFinalize(ce) afin d'en informer les garbage collector que mon objet a déjà été nettoyé. Je le fais parce que l'appel de la GC est coûteux en fonctionnement.
5. Comme précaution supplémentaire, j'essaie de rendre possible l'appel de Disposer() plusieurs fois.
6. J'ai parfois ajouter un membre privé _disposed et vérifiez dans les appels de méthode a fait l'objet a été nettoyé. Et si il a été nettoyé puis générer ObjectDisposedException
  
  Modèle suivant montre ce que j'ai décrit dans les mots de l'échantillon de code:
```
public class SomeClass : IDisposable
    {
        ///<summary>
        ///As usually I don't care was object disposed or not
        ///</summary>
        public void SomeMethod()
        {
            if (_disposed)
                throw new ObjectDisposedException("SomeClass instance been disposed");
        }

        public void Dispose()
        {
            Dispose(true);
        }

        private bool _disposed;

        protected virtual void Dispose(bool disposing)
        {
            if (_disposed)
                return;
            if (disposing)//we are in the first call
            {
            }
            _disposed = true;
        }
    }
```
- "Pour moi non managé des ressources signifie qu'une classe qui implémente l'interface IDisposable ou quelque chose de créé avec l'utilisation des appels à la dll". Vous dites que n'importe quel type qui is IDisposable doit lui-même être considéré comme une ressource non managée? Cela ne semble pas correcte. Aussi, si le implmenting type est un pur type de valeur que vous semblez suggérer qu'il n'a pas besoin d'être éliminés. Cela semble aussi être mauvais.
- Tout le monde en juge par lui-même. Je n'aime pas à ajouter à la mine de code quelque chose juste pour le plaisir de plus. Cela signifie que si j'ajoute IDisposable, cela signifie que j'ai créé un genre de fonctionnalités que GC ne pouvez pas gérer ou je suppose qu'il ne sera pas en mesure de gérer sa vie correctement.
InformationsquelleAutor Yuriy Zaletskyy
2

Les plus justifiable en cas d'utilisation pour l'élimination de la gestion des ressources, la préparation de la conférence de récupérer des ressources qui seraient autrement jamais être collecté.

En est un excellent exemple des références circulaires.

Tandis qu'il est préférable d'utiliser des modèles qui permettent d'éviter les références circulaires, si vous vous retrouvez avec (par exemple) un 'enfant' objet qui a une référence à ses "parents", ce qui peut arrêter GC collection de la société mère si vous venez d'abandonner la référence et de s'appuyer sur GC - de plus, si vous avez mis en place un outil de finalisation, ce ne sera jamais appelé.

Le seul chemin de ronde, c'est manuellement rompre les références circulaires en définissant le Parent références à null sur les enfants.

La mise en œuvre de IDisposable des parents et des enfants est la meilleure façon de le faire. Lorsque Disposer est appelée sur le Parent, appelez dispose sur tous les Enfants, et à l'enfant de Disposer de la méthode, définir le Parent références à null.
- Pour la plupart, la GC ne fonctionne pas par l'identification des objets morts, mais plutôt par l'identification de ceux qui sont vivants. Après chaque cycle de gc, pour chaque objet qui l'a enregistré pour finallization, est stocké sur le tas d'objets volumineux, ou est la cible d'un live WeakReference, le système va vérifier un indicateur qui indique qu'un live enracinée de référence a été trouvé dans le dernier cycle de GC, et pour ajouter l'objet d'une file d'attente d'objets ayant besoin immédiat de finalisation, la libération de l'objet à partir de la grand tas d'objets, ou d'invalider la référence faible. Circulaire refs ne sera pas garder les objets en vie si pas d'autres références existent.
InformationsquelleAutor controlbox

Votre exemple de code n'est pas un bon exemple pour IDisposable d'utilisation. Dictionnaire de compensation normalement ne devrait pas aller à l' Dispose méthode. Des éléments dans le dictionnaire sera effacée et disposé quand elle est hors de portée. IDisposable mise en œuvre est nécessaire pour libérer de la mémoire/des gestionnaires qui ne sera pas de presse/libre, même après qu'ils hors de portée.

L'exemple suivant montre un bon exemple pour IDisposable modèle avec un peu de code et des commentaires.

public class DisposeExample
{
//A base class that implements IDisposable. 
//By implementing IDisposable, you are announcing that 
//instances of this type allocate scarce resources. 
public class MyResource: IDisposable
{
//Pointer to an external unmanaged resource. 
private IntPtr handle;
//Other managed resource this class uses. 
private Component component = new Component();
//Track whether Dispose has been called. 
private bool disposed = false;
//The class constructor. 
public MyResource(IntPtr handle)
{
this.handle = handle;
}
//Implement IDisposable. 
//Do not make this method virtual. 
//A derived class should not be able to override this method. 
public void Dispose()
{
Dispose(true);
//This object will be cleaned up by the Dispose method. 
//Therefore, you should call GC.SupressFinalize to 
//take this object off the finalization queue 
//and prevent finalization code for this object 
//from executing a second time.
GC.SuppressFinalize(this);
}
//Dispose(bool disposing) executes in two distinct scenarios. 
//If disposing equals true, the method has been called directly 
//or indirectly by a user's code. Managed and unmanaged resources 
//can be disposed. 
//If disposing equals false, the method has been called by the 
//runtime from inside the finalizer and you should not reference 
//other objects. Only unmanaged resources can be disposed. 
protected virtual void Dispose(bool disposing)
{
//Check to see if Dispose has already been called. 
if(!this.disposed)
{
//If disposing equals true, dispose all managed 
//and unmanaged resources. 
if(disposing)
{
//Dispose managed resources.
component.Dispose();
}
//Call the appropriate methods to clean up 
//unmanaged resources here. 
//If disposing is false, 
//only the following code is executed.
CloseHandle(handle);
handle = IntPtr.Zero;
//Note disposing has been done.
disposed = true;
}
}
//Use interop to call the method necessary 
//to clean up the unmanaged resource.
[System.Runtime.InteropServices.DllImport("Kernel32")]
private extern static Boolean CloseHandle(IntPtr handle);
//Use C# destructor syntax for finalization code. 
//This destructor will run only if the Dispose method 
//does not get called. 
//It gives your base class the opportunity to finalize. 
//Do not provide destructors in types derived from this class.
~MyResource()
{
//Do not re-create Dispose clean-up code here. 
//Calling Dispose(false) is optimal in terms of 
//readability and maintainability.
Dispose(false);
}
}
public static void Main()
{
//Insert code here to create 
//and use the MyResource object.
}
}

InformationsquelleAutor CharithJ

0

Je vois beaucoup de réponses ont commencé à parler à l'aide de IDisposable administrés et des ressources non managées. Je vous suggère cet article comme l'une des meilleures explications que j'ai trouvé pour combien de IDisposable doit être utilisé.

https://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About

Pour la question réelle; si vous utilisez IDisposable pour nettoyer des objets gérés qui prennent beaucoup de mémoire, la réponse courte serait pas. La raison en est que, une fois que vous disposez d'un IDisposable vous devriez le laisser aller hors de portée. À ce point, tout enfant référencé objets sont hors de portée et aurez recueillis.

La seule véritable exception à cette règle serait si vous avez beaucoup de mémoire liée à des objets gérés et que vous avez bloqué le thread de l'attente d'une opération. Si ces objets où ne va pas être nécessaire après que l'appel est terminé, puis la création de ces références à la valeur null peut permettre le garbage collector pour collecter plus tôt. Mais ce scénario se représenter mauvais code que nécessaire pour être réusiné - pas un cas d'utilisation de IDisposable.
- Je n'ai pas compris pourquoi somehone mettre -1 à votre réponse
InformationsquelleAutor MikeJ

Vous devez vous connecter pour publier un commentaire.

Pourrais-je ne pas utiliser Finaliser pour le nettoyage de ressources non managées?

Bonus De Lecture

Bonus Supplémentaire De Lecture