Utilisation destructor/finaliser cher?

Question

Je suis occupé à être confus au sujet de la destruction non-déterministe. Dans une réponse à un autre question j'ai reçu le conseil que les destructeurs/finaliseurs (que je suppose être la même chose dans C#, c'est-à-dire la fonction appelée ~ classname()) sont chers et non requis. Mais en regardant this par exemple un destructeur est utilisé et à partir du commentaire sonne comme il peut être vital. Quelqu'un a-t-il reçu des conseils sur la façon dont tout cela s'accorde et dois-je retirer le destructeur de mon code?

Merci encore.

Answer 1

Vous ne devez inclure un finaliseur que si a absolument pour effectuer un nettoyage à un moment donné, qu'il soit exécuté explicitement ou non. Dans de tels cas, vous devriez toujours avoir un moyen explicite d'effectuer le nettoyage en temps opportun de toute façon, et cela devrait supprimer la finalisation de toute façon, afin que les «bons» clients ne voient aucune pénalité de performance.

Vous normalement besoin d'un finaliseur si vous avez une poignée directe aux ressources non gérés - si vous avez seulement une référence à une autre classe qui a une poignée sur la ressource (par exemple FileStream) alors vous devriez laisser à la autre classe pour avoir un finaliseur.

Avec l'avènement de SafeHandle dans .NET 2.0, les situations où il vaut la peine d'écrire votre propre finaliseur sont very rare indeed. La pénalité de performance des finaliseurs est qu'ils font vivre vos objets plus longtemps qu'ils n'en ont besoin: dans le premier cycle du GC où ils sont considérés comme éligibles à la collecte, ils sont placés dans la file d'attente du la prochaine génération comme tout autre objet qui survit à un cycle GC. Le finaliseur s'exécutera ensuite dans un autre thread (à un moment donné) et seulement puis seront-ils éligibles pour être réellement collectés. Donc, au lieu de (disons) être recueillis dans la première collection gen1, ils vivent sur cette collection jusqu'à la prochaine gen2, ce qui peut être considérablement plus tard.

Answer 2

Habituellement, l'implémentation d'un destructeur est utile dans le cas où: lorsqu'il n'est pas garanti, ce code client ferme correctement toutes les ressources (flux de fichiers, connexions db etc.). Donc, si le code client échoue à le faire, vous aurez du code, qui le fermera, ce qui est mieux que de laisser les ressources ouvertes.

Answer 3

Vous avez uniquement besoin du modèle jetable complet lorsque vous traitez directement avec une ressource non gérée. Et puis c'est à votre code appelant de vous assurer que le destructeur n'est (presque) jamais utilisé.

Lorsque vous traitez avec des ressources gérées (= propriété indirecte des ressources non gérés), le destructor est inutile:

class FileWrapper 
{ 
    private FileStream fs; // managed resource 

    ~FileWrapper() 
    { 
     if (fs != null) 
      fs.Dispose(); // fs is already on the GC finalizer queue 
    } 
} 

Chaque fois qu'un objet FileWrapper est recueilli par le GC, il est certain que l'objet fs est le même lot. L'appel à fs.Dispose() est donc inutile, ne testant que le comportement correct (permettant plusieurs appels) du FileStream.Dispose().

Le seul destructeur utile ici est celui de FileStream.