L'utilisation de Finaliser/méthode dispose en C#

Recommandé IDisposable modèle est ici. Lors de la programmation d'une classe qui utilise IDisposable, en règle générale, vous devez utiliser deux modèles:

Lors de l'implémentation d'une classe scellée qui n'utilise pas les ressources non managées, il vous suffit de mettre en œuvre une méthode dispose, tout comme avec les implémentations d'interface:

public sealed class A : IDisposable
{
    public void Dispose()
    {
        //get rid of managed resources, call Dispose on member variables...
    }
}

Lors de la mise en œuvre d'un descellés classe, de faire comme ceci:

public class B : IDisposable
{    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            //get rid of managed resources
        }   
        //get rid of unmanaged resources
    }

    //only if you use unmanaged resources directly in B
    //~B()
    //{
    //   Dispose(false);
    //}
}

Avis que je n'ai pas déclaré un finaliseur dans B; vous devez seulement mettre en œuvre un finaliseur si vous avez de réelles ressources non managées d'en disposer. Le CLR traite finalisable objets différemment à la non-finalisable objets, même si SuppressFinalize est appelé.

Donc, vous ne devez pas déclarer un finaliseur, sauf si vous devez, mais vous donnez les héritiers de votre classe un crochet pour appeler votre Dispose et de mettre en œuvre un finaliseur s'ils utilisent des ressources non gérées directement:

public class C : B
{
    private IntPtr m_Handle;

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            //get rid of managed resources
        }
        ReleaseHandle(m_Handle);

        base.Dispose(disposing);
    }

    ~C() {
        Dispose(false);
    }
}

Si vous n'êtes pas en utilisant des ressources non gérées directement (SafeHandle et amis ne comptent pas, qu'ils le disent leurs propres outils de finalisation), alors ne pas mettre en œuvre un outil de finalisation, comme le gouvernement du canada traite finalisable classes différemment, même si plus tard vous souhaitez supprimer l'outil de finalisation. À noter également que, même si B ne dispose pas d'un outil de finalisation, il appelle encore SuppressFinalize de traiter correctement toutes les sous-classes qui n'en œuvre d'un outil de finalisation.

Lorsqu'une classe implémente l'interface IDisposable, cela signifie que quelque part il y a quelques ressources non managées, qui devrait être de s'en débarrasser lorsque vous avez fini d'utiliser la classe. Les ressources actuelles sont encapsulés dans les classes; vous ne devez pas explicitement les supprimer. Simplement en appelant Dispose() ou emballage de la classe dans un using(...) {} sera assurez-vous que toutes les ressources non managées sont de s'en débarrasser comme nécessaire.

Noter que toute IDisposable mise en œuvre doit suivre le schéma ci-dessous (à mon humble avis). J'ai développé ce modèle basé sur des informations à partir de plusieurs excellents .NET des "dieux" de la .NET Cadre des lignes Directrices de Conception (notez que MSDN ne pas suivre ce pour quelque raison!). L' .NET Framework de Conception de lignes Directrices ont été rédigées par Krzysztof Cwalina (CLR Architecte à l'époque) et Brad Abrams (je crois que le CLR Gestionnaire de Programme à l'époque) et le projet de Loi Wagner ([Efficaces C#] et [Plus Efficace C#] (il suffit de prendre un coup d'oeil pour ces sur Amazon.com:

Noter que vous ne devriez JAMAIS mettre en œuvre un outil de finalisation, à moins que votre classe contient directement (pas en hérite) des ressources non managées. Une fois que vous mettre en œuvre un outil de finalisation dans une classe, même si elle n'est jamais appelée, c'est la garantie de vivre une collecte supplémentaire. Il est automatiquement placé dans la File d'attente de Finalisation (qui s'exécute sur un seul thread). Aussi, on remarque très importante...tout le code exécuté dans un Finaliseur (si vous avez besoin de mettre en œuvre un) DOIT être thread-safe ET d'exception-safe! Les MAUVAISES choses vont se passer autrement...(c'est à dire indéterminé comportement et, dans le cas d'une exception, une fatale irrécupérable plantage de l'application).

Le modèle que j'ai mis en place (et écrit un extrait de code pour) suit:

#region IDisposable implementation
//TODO remember to make this class inherit from IDisposable -> $className$ : IDisposable
//Default initialization for a bool is 'false'
private bool IsDisposed { get; set; }
///<summary>
///Implementation of Dispose according to .NET Framework Design Guidelines.
///</summary>
///<remarks>Do not make this method virtual.
///A derived class should not be able to override this method.
///</remarks>
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.
//Always use SuppressFinalize() in case a subclass
//of this type implements a finalizer.
GC.SuppressFinalize( this );
}
///<summary>
///Overloaded Implementation of Dispose.
///</summary>
///<param name="isDisposing"></param>
///<remarks>
///<para><list type="bulleted">Dispose(bool isDisposing) executes in two distinct scenarios.
///<item>If <paramref name="isDisposing"/> equals true, the method has been called directly
///or indirectly by a user's code. Managed and unmanaged resources
///can be disposed.</item>
///<item>If <paramref name="isDisposing"/> 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.</item></list></para>
///</remarks>
protected virtual void Dispose( bool isDisposing )
{
//TODO If you need thread safety, use a lock around these 
//operations, as well as in your methods that use the resource.
try
{
if( !this.IsDisposed )
{
if( isDisposing )
{
//TODO Release all managed resources here
$end$
}
//TODO Release all unmanaged resources here
//TODO explicitly set root references to null to expressly tell the GarbageCollector
//that the resources have been disposed of and its ok to release the memory allocated for them.
}
}
finally
{
//explicitly call the base class Dispose implementation
base.Dispose( isDisposing );
this.IsDisposed = true;
}
}
//TODO Uncomment this code if this class will contain members which are UNmanaged
//
/////<summary>Finalizer for $className$</summary>
/////<remarks>This finalizer will run only if the Dispose method does not get called.
/////It gives your base class the opportunity to finalize.
/////DO NOT provide finalizers in types derived from this class.
/////All code executed within a Finalizer MUST be thread-safe!</remarks>
// ~$className$()
// {
//    Dispose( false );
// }
#endregion IDisposable implementation

Voici le code pour la mise en œuvre de IDisposable dans une classe dérivée. Notez que vous ne devez pas explicitement la liste de l'héritage de IDisposable dans la définition de la classe dérivée.

public DerivedClass : BaseClass, IDisposable (remove the IDisposable because it is inherited from BaseClass)
protected override void Dispose( bool isDisposing )
{
try
{
if ( !this.IsDisposed )
{
if ( isDisposing )
{
//Release all managed resources here
}
}
}
finally
{
//explicitly call the base class Dispose implementation
base.Dispose( isDisposing );
}
}

J'ai posté cette application sur mon blog: Comment mettre Correctement en Œuvre le Modèle dispose

À l'aide de lambda au lieu de IDisposable.

Je n'ai jamais été heureux avec l'ensemble à l'aide de/IDisposable idée. Le problème est qu'il nécessite l'appelant:

• savent qu'ils doivent utiliser IDisposable
• n'oubliez pas d'utiliser 'l'aide'.

Ma nouvelle méthode préférée consiste à utiliser une méthode de fabrique et un lambda au lieu

Imaginez que je veux faire quelque chose avec une occurrence de SqlConnection (quelque chose qui devrait être enveloppé d'une aide). Classiquement, vous le feriez

using (Var conn = Factory.MakeConnection())
{
conn.Query(....);
}

Nouvelle façon

Factory.DoWithConnection((conn)=>
{
conn.Query(...);
}

Dans le premier cas, l'appelant pouvait tout simplement pas utiliser l'aide de la syntaxe. DANS le second cas, l'utilisateur n'a pas le choix. Il n'existe pas de méthode qui crée un objet SqlConnection, l'appelant doit invoquer DoWithConnection.

DoWithConnection ressemble à ceci

void DoWithConnection(Action<SqlConnection> action)
{
using (var conn = MakeConnection())
{
action(conn);
}
}

MakeConnection est maintenant en privé

1. Si vous utilisez d'autres objets gérés à l'aide de ressources non managées, il n'est pas de votre responsabilité de vous assurer que les personnes sont finalisés. Votre responsabilité est d'appeler dispose sur ces objets lorsque Disposer est appelée sur votre objet, et ça s'arrête là.

2. Si votre classe n'utilise pas toutes les ressources rares, je ne vois pas pourquoi vous voulez faire de votre classe en œuvre IDisposable. Vous devriez le faire que si vous êtes:

   • Savez que vous aurez des ressources rares dans vos objets rapidement, tout simplement pas maintenant (et je veux dire que, comme dans "nous sommes encore en développement, il sera ici avant que nous ayons terminé", pas comme dans "je pense que nous en aurons besoin")
   • L'utilisation des maigres ressources

3. Oui, le code qui utilise votre code doit appeler la méthode dispose de l'objet. Et oui, le code qui utilise votre objet peut utiliser using comme vous l'avez indiqué.

4. (2?) Il est probable que le client web utilise des ressources non managées, ou d'autres ressources que de mettre en œuvre IDisposable. La raison exacte, cependant, n'est pas important. Ce qui est important, c'est qu'il met en œuvre IDisposable, et il tombe sur vous pour agir en fonction de cette connaissance par l'élimination de l'objet lorsque vous avez terminé avec lui, même si il s'avère que le client web n'utilise pas d'autres ressources.

Certains aspects de une autre réponse sont légèrement incorrect pour 2 raisons:

D'abord,

using(NoGateway objNoGateway = new NoGateway())

est en fait équivalent à:

try
{
NoGateway = new NoGateway();
}
finally
{
if(NoGateway != null)
{
NoGateway.Dispose();
}
}

Cela peut sembler ridicule, depuis la "nouvelle" de l'opérateur ne doit jamais retourner 'null', sauf si vous avez une exception OutOfMemory. Mais considérons les cas suivants:
1. Vous appelez un FactoryClass qui renvoie un IDisposable de ressources ou
2. Si vous avez un type qui peut ou ne peut pas hériter de IDisposable en fonction de sa mise en œuvre - n'oubliez pas que j'ai vu la IDisposable modèle mis en œuvre de manière incorrecte à de nombreuses reprises à de nombreux clients où les développeurs il suffit d'ajouter une méthode dispose() sans hériter de IDisposable (mauvaise, mauvaise, mauvaise). Vous pourriez également avoir le cas d'une IDisposable ressource a été obtenu à partir d'une propriété ou d'une méthode (encore une fois mauvais, mauvais, mauvais - ne pas " donner votre IDisposable ressources)

using(IDisposable objNoGateway = new NoGateway() as IDisposable)
{
if (NoGateway != null)
{
...

Si le "comme" de l'opérateur renvoie la valeur null (ou de la propriété ou de la méthode de retour de la ressource), et de votre code dans le "utilise" bloc protège contre les 'null', votre code ne sera pas sauter lorsque vous essayez d'appeler Disposer sur un objet nul en raison de la "intégrée" null vérifier.

La deuxième raison, votre réponse n'est pas exact, c'est pour les raisons suivantes stmt:

Un finaliseur est appelé lors de la GC de détruire votre objet

D'abord, la Finalisation (ainsi que GC) est non-déterministe. Le CLR détermine le moment où il va appeler un finaliseur. c'est à dire le développeur/code n'a aucune idée. Si la IDisposable modèle est correctement mis en œuvre (comme je l'ai posté ci-dessus) et GC.SuppressFinalize() a été appelée, le Finaliseur ne sera PAS appelé. C'est l'une des raisons majeures à mettre en œuvre correctement le modèle correctement. Depuis il est à seulement 1 Finaliseur thread par processus de gestion, quel que soit le nombre de processeurs logiques, vous pouvez facilement dégrader les performances en sauvegardant ou même suspendus le Finaliseur thread par l'oubli de l'appeler GC.SuppressFinalize().

J'ai posté une mise en œuvre correcte du Modèle dispose sur mon blog: Comment mettre Correctement en Œuvre le Modèle dispose

Modèle à partir de msdn

public class BaseResource: IDisposable
{
private IntPtr handle;
private Component Components;
private bool disposed = false;
public BaseResource()
{
}
public void Dispose()
{
Dispose(true);      
GC.SuppressFinalize(this);
}
protected virtual void Dispose(bool disposing)
{
if(!this.disposed)
{        
if(disposing)
{
Components.Dispose();
}         
CloseHandle(handle);
handle = IntPtr.Zero;
}
disposed = true;         
}
~BaseResource()      
{      Dispose(false);
}
public void DoSomething()
{
if(this.disposed)
{
throw new ObjectDisposedException();
}
}
}
public class MyResourceWrapper: BaseResource
{
private ManagedResource addedManaged;
private NativeResource addedNative;
private bool disposed = false;
public MyResourceWrapper()
{
}
protected override void Dispose(bool disposing)
{
if(!this.disposed)
{
try
{
if(disposing)
{             
addedManaged.Dispose();         
}
CloseHandle(addedNative);
this.disposed = true;
}
finally
{
base.Dispose(disposing);
}
}
}
}

De ce que je sais, il est fortement recommandé de ne PAS utiliser l'outil de finalisation /Destructeur:

public ~MyClass() {
//dont use this
}

Plupart du temps, cela est dû à ne pas savoir quand il va être appelé. La méthode dispose est beaucoup mieux, surtout si vous nous utiliser ou de disposer directement.

l'aide est bonne. l'utiliser 🙂