Utilisation de la méthode Finalize / Dispose en C #

C # 2008

J'y travaille depuis un certain temps maintenant, et je suis toujours confus quant à l'utilisation des méthodes de finalisation et d'élimination dans le code. Mes questions sont ci-dessous:

1. Je sais que nous n'avons besoin que d'un finaliseur pour disposer de ressources non gérées. Cependant, s'il existe des ressources gérées qui appellent des ressources non gérées, aurait-il encore besoin d'implémenter un finaliseur?

2. Cependant, si je développe une classe qui n'utilise aucune ressource non gérée - directement ou indirectement, dois-je implémenter le IDisposablepour autoriser les clients de cette classe à utiliser «l'instruction using»?

   Serait-il possible d'implémenter IDisposable juste pour permettre aux clients de votre classe d'utiliser l'instruction using?

   using(myClass objClass = new myClass())
   {
       // Do stuff here
   }

3. J'ai développé ce code simple ci-dessous pour démontrer l'utilisation de Finaliser / éliminer:

   public class NoGateway : IDisposable
   {
       private WebClient wc = null;
   
       public NoGateway()
       {
           wc = new WebClient();
           wc.DownloadStringCompleted += wc_DownloadStringCompleted;
       }
   
   
       // Start the Async call to find if NoGateway is true or false
       public void NoGatewayStatus()
       {
           // Start the Async's download
               // Do other work here
           wc.DownloadStringAsync(new Uri(www.xxxx.xxx));
       }
   
       private void wc_DownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e)
       {
           // Do work here
       }
   
       // Dispose of the NoGateway object
       public void Dispose()
       {
           wc.DownloadStringCompleted -= wc_DownloadStringCompleted;
           wc.Dispose();
           GC.SuppressFinalize(this);
       }
   }

Question sur le code source:

1. Ici, je n'ai pas ajouté le finaliseur, et normalement le finaliseur sera appelé par le GC, et le finaliseur appellera Dispose. Comme je n'ai pas le finaliseur, quand dois-je appeler la méthode Dispose? Est-ce le client de la classe qui doit l'appeler?

   Donc ma classe dans l'exemple s'appelle NoGateway et le client pourrait utiliser et éliminer la classe comme ceci:

   using(NoGateway objNoGateway = new NoGateway())
   {
       // Do stuff here   
   }

   La méthode Dispose serait-elle automatiquement appelée lorsque l'exécution atteindrait la fin du bloc using, ou le client doit-il appeler manuellement la méthode Dispose? c'est à dire

   NoGateway objNoGateway = new NoGateway();
   // Do stuff with object
   objNoGateway.Dispose(); // finished with it

2. J'utilise la WebClientclasse dans ma NoGatewayclasse. Parce WebClientqu'implémente l' IDisposableinterface, cela signifie-t-il que WebClientindirectement utilise des ressources non gérées? Existe-t-il une règle stricte et rapide pour suivre cela? Comment savoir qu'une classe utilise des ressources non managées?

Le modèle IDisposable recommandé est ici . Lors de la programmation d'une classe qui utilise IDisposable, vous devez généralement utiliser deux modèles:

Lorsque vous implémentez une classe scellée qui n'utilise pas de ressources non managées, vous implémentez simplement une méthode Dispose comme avec les implémentations d'interface normales:

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

Lorsque vous implémentez une classe non scellée, procédez comme suit:

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);
    //}
}

Notez que je n'ai pas déclaré de finaliseur dans B; vous ne devez implémenter un finaliseur que si vous disposez de ressources réelles non gérées à éliminer. Le CLR traite les objets finalisables différemment des objets non finalisables, même s'il SuppressFinalizeest appelé.

Donc, vous ne devez pas déclarer un finaliseur sauf si vous le devez, mais vous donnez aux héritiers de votre classe un hook pour appeler votre Disposeet implémenter un finaliseur eux-mêmes s'ils utilisent directement des ressources non managées:

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'utilisez pas directement des ressources non gérées ( SafeHandleet que les amis ne comptent pas, car ils déclarent leurs propres finaliseurs), n'implémentez pas de finaliseur, car le GC traite les classes finalisables différemment, même si vous supprimez plus tard le finaliseur. Notez également que, même s'il Bn'a pas de finaliseur, il appelle toujours SuppressFinalizepour traiter correctement les sous-classes qui implémentent un finaliseur.

Lorsqu'une classe implémente l'interface IDisposable, cela signifie qu'il existe quelque part des ressources non gérées dont vous devez vous débarrasser lorsque vous avez fini d'utiliser la classe. Les ressources réelles sont encapsulées dans les classes; vous n'avez pas besoin de les supprimer explicitement. Un simple appel Dispose()ou encapsulation de la classe dans a using(...) {}vous permettra de vous débarrasser de toutes les ressources non gérées si nécessaire.

Le modèle officiel à mettre en œuvre IDisposableest difficile à comprendre. Je crois que celui-ci est meilleur :

public class BetterDisposableClass : IDisposable {

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

  protected virtual void CleanUpManagedResources() { 
    // ...
  }
  protected virtual void CleanUpNativeResources() {
    // ...
  }

  ~BetterDisposableClass() {
    CleanUpNativeResources();
  }

}

Une solution encore meilleure consiste à avoir une règle selon laquelle vous devez toujours créer une classe wrapper pour toute ressource non managée que vous devez gérer:

public class NativeDisposable : IDisposable {

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

  protected virtual void CleanUpNativeResource() {
    // ...
  }

  ~NativeDisposable() {
    CleanUpNativeResource();
  }

}

Avec SafeHandleet ses dérivés, ces classes devraient être très rares .

Le résultat pour les classes jetables qui ne traitent pas directement avec les ressources non managées, même en présence d'héritage, est puissant: elles n'ont plus besoin de se préoccuper des ressources non managées . Ils seront simples à mettre en œuvre et à comprendre:

public class ManagedDisposable : IDisposable {

  public virtual void Dispose() {
    // dispose of managed resources
  }

}

Notez que toute mise en œuvre IDisposable doit suivre le modèle ci-dessous (à mon humble avis). J'ai développé ce modèle sur la base des informations provenant de plusieurs excellents «dieux» .NET des directives de conception du .NET Framework (notez que MSDN ne suit pas cela pour une raison quelconque!). Les lignes directrices de conception du .NET Framework ont ​​été écrites par Krzysztof Cwalina (architecte CLR à l'époque) et Brad Abrams (je crois que le responsable du programme CLR à l'époque) et Bill Wagner ([Effective C #] et [More Effective C #] (prenez simplement un recherchez-les sur Amazon.com:

Notez que vous ne devez JAMAIS implémenter un Finalizer à moins que votre classe ne contienne directement (et n'hérite pas) des ressources UNmanaged. Une fois que vous implémentez un Finalizer dans une classe, même s'il n'est jamais appelé, il est garanti de vivre pour une collection supplémentaire. Il est automatiquement placé dans la file d'attente de finalisation (qui s'exécute sur un seul thread). De plus, une note très importante ... tout le code exécuté dans un Finalizer (si vous devez en implémenter un) DOIT être thread-safe ET exception-safe! MAUVAISES choses se produiront autrement ... (c'est-à-dire un comportement indéterminé et dans le cas d'une exception, un plantage fatal irrécupérable 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 implémenter IDisposable dans une classe dérivée. Notez que vous n'avez pas besoin de répertorier explicitement l'héritage d'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 publié cette implémentation sur mon blog à: Comment implémenter correctement le modèle de suppression

Je suis d' accord avec pm100 (et j'aurais dû le dire explicitement dans mon post précédent).

Vous ne devez jamais implémenter IDisposable dans une classe à moins d'en avoir besoin. Pour être très précis, il y a environ 5 fois où vous auriez besoin / devriez implémenter IDisposable:

1. Votre classe contient explicitement (c'est-à-dire pas via l'héritage) toutes les ressources gérées qui implémentent IDisposable et doivent être nettoyées une fois que votre classe n'est plus utilisée. Par exemple, si votre classe contient une instance d'un Stream, DbCommand, DataTable, etc.

2. Votre classe contient explicitement toutes les ressources gérées qui implémentent une méthode Close () - par exemple IDataReader, IDbConnection, etc. Notez que certaines de ces classes implémentent IDisposable en ayant Dispose () ainsi qu'une méthode Close ().

3. Votre classe contient explicitement une ressource non gérée - par exemple un objet COM, des pointeurs (oui, vous pouvez utiliser des pointeurs en C # géré mais ils doivent être déclarés dans des blocs "non sécurisés", etc. Dans le cas de ressources non gérées, vous devez également vous assurer de appelez System.Runtime.InteropServices.Marshal.ReleaseComObject () sur le RCW. Même si le RCW est, en théorie, un wrapper managé, il y a toujours un comptage de références en cours sous les couvertures.

4. Si votre classe s'abonne à des événements en utilisant des références fortes. Vous devez vous désinscrire / vous détacher des événements. Assurez-vous toujours que ceux-ci ne sont pas nuls avant d'essayer de les désenregistrer / les détacher!.

5. Votre classe contient toute combinaison des éléments ci-dessus ...

Une alternative recommandée à l'utilisation d'objets COM et à l'utilisation de Marshal.ReleaseComObject () consiste à utiliser la classe System.Runtime.InteropServices.SafeHandle.

La BCL (Base Class Library Team) a un bon blog à ce sujet ici http://blogs.msdn.com/bclteam/archive/2005/03/16/396900.aspx

Une note très importante à faire est que si vous travaillez avec WCF et que vous nettoyez des ressources, vous devriez PRESQUE TOUJOURS éviter le bloc "using". Il existe de nombreux articles de blog et certains sur MSDN expliquant pourquoi c'est une mauvaise idée. J'ai également posté à ce sujet ici - N'utilisez pas 'using ()' avec un proxy WCF

Utilisation de lambdas au lieu d'IDisposable.

Je n'ai jamais été ravi de l'idée d'utiliser / IDisposable. Le problème est qu'il nécessite que l'appelant:

• savent qu'ils doivent utiliser IDisposable
• n'oubliez pas d'utiliser «en utilisant».

Ma nouvelle méthode préférée consiste à utiliser une méthode d'usine et un lambda à la place

Imaginez que je veux faire quelque chose avec un SqlConnection (quelque chose qui devrait être enveloppé dans une utilisation). Classiquement, vous feriez

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

Nouvelle façon

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

Dans le premier cas, l'appelant ne pouvait tout simplement pas utiliser la syntaxe using. Dans le second cas, l'utilisateur n'a pas le choix. Aucune méthode ne crée un objet SqlConnection, l'appelant doit appeler DoWithConnection.

DoWithConnection ressemble à ceci

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

MakeConnection est maintenant privé

personne n'a répondu à la question de savoir si vous devez implémenter IDisposable même si vous n'en avez pas besoin.

Réponse courte: Non

Longue réponse:

Cela permettrait à un consommateur de votre classe d'utiliser «using». La question que je poserais est - pourquoi le feraient-ils? La plupart des développeurs n'utiliseront pas «à l'aide» à moins qu'ils ne sachent qu'ils doivent - et comment savent-ils. Soit

• ses obviuos les d'expérience (une classe de socket par exemple)
• son documenté
• ils sont prudents et peuvent voir que la classe implémente IDisposable

Donc, en implémentant IDisposable, vous dites aux développeurs (au moins certains) que cette classe termine quelque chose qui doit être publié. Ils utiliseront «using» - mais il y a d'autres cas où l'utilisation n'est pas possible (la portée de l'objet n'est pas locale); et ils devront commencer à s'inquiéter de la durée de vie des objets dans ces autres cas - je m'inquiéterais à coup sûr. Mais ce n'est pas nécessaire

Vous implémentez Idisposable pour leur permettre d'utiliser en utilisant, mais ils n'utiliseront pas en utilisant à moins que vous leur dites.

Alors ne le fais pas

1. Si vous utilisez d'autres objets gérés qui utilisent des ressources non gérées, il n'est pas de votre responsabilité de vous assurer qu'ils sont finalisés. Votre responsabilité est d'appeler Dispose sur ces objets lorsque Dispose est appelé sur votre objet, et cela s'arrête là.

2. Si votre classe n'utilise pas de ressources rares, je ne vois pas pourquoi vous voudriez que votre classe implémente IDisposable. Vous ne devez le faire que si vous êtes:

   • Sachez que vous aurez bientôt des ressources rares dans vos objets, mais pas maintenant (et je veux dire que comme dans "nous continuons à développer, ce sera ici avant que nous ayons terminé", pas comme dans "je pense que nous en aurons besoin ")
   • Utiliser des ressources rares

3. Oui, le code qui utilise votre code doit appeler la méthode Dispose de votre objet. Et oui, le code qui utilise votre objet peut utiliser usingcomme vous l'avez montré.

4. (2 encore?) Il est probable que le WebClient utilise des ressources non managées ou d'autres ressources managées qui implémentent IDisposable. La raison exacte, cependant, n'est pas importante. Ce qui est important, c'est qu'il implémente IDisposable, et il vous incombe donc d'agir sur cette connaissance en éliminant l'objet lorsque vous en avez terminé, même s'il s'avère que WebClient n'utilise aucune autre ressource.

Éliminer le motif:

public abstract class DisposableObject : IDisposable
{
    public bool Disposed { get; private set;}      

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

    ~DisposableObject()
    {
        Dispose(false);
    }

    private void Dispose(bool disposing)
    {
        if (!Disposed)
        {
            if (disposing)
            {
                DisposeManagedResources();
            }

            DisposeUnmanagedResources();
            Disposed = true;
        }
    }

    protected virtual void DisposeManagedResources() { }
    protected virtual void DisposeUnmanagedResources() { }
}

Exemple d'héritage:

public class A : DisposableObject
{
    public Component components_a { get; set; }
    private IntPtr handle_a;

    protected override void DisposeManagedResources()
    {
        try
        {
          Console.WriteLine("A_DisposeManagedResources");
          components_a.Dispose();
          components_a = null;
        }
        finally
        { 
          base.DisposeManagedResources();
        }
    }

    protected override void DisposeUnmanagedResources()
    {
        try
        {
          Console.WriteLine("A_DisposeUnmanagedResources");
          CloseHandle(handle_a);
          handle_a = IntPtr.Zero;
        }
        finally
        { 
          base.DisposeUnmanagedResources();
        }
    }
}

public class B : A
{
    public Component components_b { get; set; }
    private IntPtr handle_b;

    protected override void DisposeManagedResources()
    {
        try
        {
          Console.WriteLine("B_DisposeManagedResources");
          components_b.Dispose();
          components_b = null;
        }
        finally
        { 
          base.DisposeManagedResources();
        }
    }

    protected override void DisposeUnmanagedResources()
    {
        try
        {
          Console.WriteLine("B_DisposeUnmanagedResources");
          CloseHandle(handle_b);
          handle_b = IntPtr.Zero;
        }
        finally
        { 
          base.DisposeUnmanagedResources();
        }
    }
}

Certains aspects d' une autre réponse sont légèrement incorrects pour 2 raisons:

Première,

using(NoGateway objNoGateway = new NoGateway())

est en fait équivalent à:

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

Cela peut sembler ridicule, car le «nouvel» opérateur ne doit jamais retourner «null», sauf si vous avez une exception OutOfMemory. Mais considérez les cas suivants: 1. Vous appelez une FactoryClass qui renvoie une ressource IDisposable ou 2. Si vous avez un type qui peut ou non hériter d'IDisposable en fonction de son implémentation - rappelez-vous que j'ai vu le modèle IDisposable implémenté incorrectement beaucoup parfois sur de nombreux clients où les développeurs ajoutent simplement une méthode Dispose () sans hériter d'IDisposable (mauvais, mauvais, mauvais). Vous pouvez également avoir le cas d'une ressource IDisposable renvoyée par une propriété ou une méthode (encore une fois mauvaise, mauvaise, mauvaise - ne donnez pas vos ressources IDisposable)

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

Si l'opérateur «as» renvoie null (ou une propriété ou une méthode renvoyant la ressource) et que votre code dans le bloc «using» protège contre «null», votre code ne explosera pas lorsque vous tenterez d'appeler Dispose sur un objet null en raison de la vérification nulle «intégrée».

La deuxième raison pour laquelle votre réponse n'est pas exacte est due au stmt suivant:

Un finaliseur est appelé sur le GC détruisant votre objet

Premièrement, la finalisation (ainsi que le GC lui-même) n'est pas déterministe. Le CLR détermine quand il appellera un finaliseur. c'est-à-dire que le développeur / code n'a aucune idée. Si le modèle IDisposable est correctement implémenté (comme je l'ai indiqué ci-dessus) et que GC.SuppressFinalize () a été appelé, le Finalizer ne sera PAS appelé. C'est l'une des grandes raisons de mettre correctement en œuvre le modèle correctement. Puisqu'il n'y a qu'un seul thread Finalizer par processus géré, quel que soit le nombre de processeurs logiques, vous pouvez facilement dégrader les performances en sauvegardant ou même en suspendant le thread Finalizer en oubliant d'appeler GC.SuppressFinalize ().

J'ai publié une implémentation correcte du modèle Dispose sur mon blog: Comment implémenter correctement le modèle Dispose

1) WebClient est un type géré, vous n'avez donc pas besoin d'un finaliseur. Le finaliseur est nécessaire dans le cas où vos utilisateurs ne suppriment pas () de votre classe NoGateway et le type natif (qui n'est pas collecté par le GC) doit être nettoyé après. Dans ce cas, si l'utilisateur n'appelle pas Dispose (), le WebClient contenu sera supprimé par le GC juste après le NoGateway.

2) Indirectement oui, mais vous ne devriez pas vous en soucier. Votre code est correct en l'état et vous ne pouvez pas empêcher vos utilisateurs d'oublier de Dispose () très facilement.

Modèle 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);
         }
      }
   }
}

using(NoGateway objNoGateway = new NoGateway())

est équivalent à

try
{
    NoGateway = new NoGateway();
}

finally
{
    NoGateway.Dispose();
}

Un finaliseur est appelé lorsque le GC détruit votre objet. Cela peut être à un moment totalement différent de celui où vous quittez votre méthode. Le Dispose of IDisposable est appelé immédiatement après avoir quitté le bloc using. Par conséquent, le modèle est généralement utilisé pour utiliser pour libérer des ressources immédiatement après que vous n'en ayez plus besoin.

D'après ce que je sais, il est fortement recommandé de ne PAS utiliser le Finalizer / Destructor:

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

Surtout, cela est dû au fait de ne pas savoir quand ni SI il sera appelé. La méthode d'élimination est bien meilleure, surtout si vous nous utilisez ou éliminez directement.

l'utilisation est bonne. utilise le :)