Uso do método Finalize / Dispose em C #

C # 2008

Estou trabalhando nisso há algum tempo e ainda estou confuso sobre o uso dos métodos finalize e descarte no código. Minhas perguntas estão abaixo:

1. Eu sei que precisamos apenas de um finalizador enquanto dispomos de recursos não gerenciados. No entanto, se houver recursos gerenciados que fazem chamadas para recursos não gerenciados, ainda seria necessário implementar um finalizador?

2. No entanto, se eu desenvolver uma classe que não use nenhum recurso não gerenciado - direta ou indiretamente, devo implementar o IDisposablepara permitir que os clientes dessa classe usem a 'declaração de uso'?

   Seria viável implementar IDisposable apenas para permitir que os clientes de sua classe usassem a instrução using?

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

3. Desenvolvi este código simples abaixo para demonstrar o uso Finalizar / descartar:

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

Pergunta sobre o código fonte:

1. Aqui eu não adicionei o finalizador, e normalmente o finalizador será chamado pelo GC, e o finalizador chamará Dispose. Como não tenho o finalizador, quando chamo o método Dispose? É o cliente da classe que precisa chamá-lo?

   Portanto, minha classe no exemplo é chamada NoGateway e o cliente pode usar e descartar a classe assim:

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

   O método Dispose seria chamado automaticamente quando a execução chegasse ao final do bloco using ou o cliente precisa chamar manualmente o método de descarte? ie

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

2. Eu estou usando a WebClientclasse na minha NoGatewayclasse. Como WebClientimplementa a IDisposableinterface, isso significa que WebClientindiretamente usa recursos não gerenciados? Existe uma regra rígida e rápida para seguir isso? Como sei que uma classe usa recursos não gerenciados?

O padrão IDisposable recomendado está aqui . Ao programar uma classe que usa IDisposable, geralmente você deve usar dois padrões:

Ao implementar uma classe selada que não usa recursos não gerenciados, você simplesmente implementa um método Dispose como nas implementações normais da interface:

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

Ao implementar uma classe não lacrada, faça o seguinte:

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

Observe que eu não declarei um finalizador em B; você só deve implementar um finalizador se tiver recursos não gerenciados reais para descartar. O CLR lida com objetos finalizáveis ​​de maneira diferente de objetos não finalizáveis, mesmo se SuppressFinalizefor chamado.

Portanto, você não deve declarar um finalizador, a menos que seja necessário, mas concede aos herdeiros um gancho para chamá-lo Disposee implementá-lo se eles usarem recursos não gerenciados diretamente:

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

Se você não estiver usando recursos não gerenciados diretamente ( SafeHandlee os amigos não contarem, pois declaram seus próprios finalizadores), não implemente um finalizador, pois o GC lida com classes finalizáveis ​​de maneira diferente, mesmo se você suprimir o finalizador posteriormente. Observe também que, embora Bnão tenha um finalizador, ele ainda chamaSuppressFinalize para lidar corretamente com qualquer subclasse que implementa um finalizador.

Quando uma classe implementa a interface IDisposable, significa que em algum lugar existem alguns recursos não gerenciados que devem ser eliminados quando você terminar de usar a classe. Os recursos reais são encapsulados dentro das classes; você não precisa excluí-los explicitamente. Simplesmente chamar Dispose()ou agrupar a classe em using(...) {}garantirá que todos os recursos não gerenciados sejam eliminados conforme necessário.

O padrão oficial a ser implementado IDisposableé difícil de entender. Eu acredito que este é melhor :

public class BetterDisposableClass : IDisposable {

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

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

  ~BetterDisposableClass() {
    CleanUpNativeResources();
  }

}

Uma solução ainda melhor é ter uma regra na qual você sempre deve criar uma classe de wrapper para qualquer recurso não gerenciado que você precise manipular:

public class NativeDisposable : IDisposable {

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

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

  ~NativeDisposable() {
    CleanUpNativeResource();
  }

}

Com SafeHandlee seus derivados, essas classes devem ser muito raras .

O resultado para classes descartáveis ​​que não lidam diretamente com recursos não gerenciados, mesmo na presença de herança, é poderoso: elas não precisam mais se preocupar com recursos não gerenciados . Eles serão simples de implementar e entender:

public class ManagedDisposable : IDisposable {

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

}

Observe que qualquer implementação IDisposable deve seguir o padrão abaixo (IMHO). Desenvolvi esse padrão com base nas informações de vários "deuses" excelentes do .NET Framework Guidelines do .NET Framework (observe que o MSDN não segue isso por algum motivo!). As diretrizes de design do .NET Framework foram escritas por Krzysztof Cwalina (arquiteto do CLR na época) e Brad Abrams (acredito que o CLR Program Manager na época) e Bill Wagner ([C # efetivo] e [C # mais eficaz] (apenas faça uma procure-os no Amazon.com:

Observe que NUNCA deve implementar um Finalizador, a menos que sua classe contenha diretamente (não herda) recursos NÃO gerenciados. Depois de implementar um Finalizador em uma classe, mesmo que nunca seja chamado, é garantido que você terá uma coleção extra. Ele é automaticamente colocado na fila de finalização (que é executada em um único encadeamento). Além disso, uma observação muito importante ... todo o código executado dentro de um Finalizador (caso seja necessário implementar uma) DEVE ser seguro para threads E seguro para exceções! Coisas ruins acontecerão de outra forma ... (ou seja, comportamento indeterminado e, no caso de uma exceção, uma falha fatal irrecuperável do aplicativo).

O padrão que eu montei (e escrevi um trecho de código) é o seguinte:

#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

Aqui está o código para implementar IDisposable em uma classe derivada. Observe que você não precisa listar explicitamente a herança de IDisposable na definição da classe derivada.

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

Publiquei esta implementação no meu blog em: Como implementar corretamente o padrão de descarte

Concordo com o pm100 (e deveria ter dito isso explicitamente no meu post anterior).

Você nunca deve implementar IDisposable em uma classe, a menos que precise. Para ser muito específico, há cerca de 5 vezes em que você precisa / deve implementar o IDisposable:

1. Sua classe contém explicitamente (ou seja, não por herança) quaisquer recursos gerenciados que implementam IDisposable e devem ser limpos assim que sua classe não for mais usada. Por exemplo, se sua classe contiver uma instância de um Stream, DbCommand, DataTable etc.

2. Sua classe contém explicitamente quaisquer recursos gerenciados que implementam um método Close () - por exemplo, IDataReader, IDbConnection, etc. Observe que algumas dessas classes implementam IDisposable por ter Dispose () e um método Close ().

3. Sua classe contém explicitamente um recurso não gerenciado - por exemplo, um objeto COM, ponteiros (sim, você pode usar ponteiros em C # gerenciado, mas eles devem ser declarados em blocos 'não seguros' etc.) No caso de recursos não gerenciados, verifique também se chame System.Runtime.InteropServices.Marshal.ReleaseComObject () no RCW Embora o RCW seja, em teoria, um invólucro gerenciado, ainda há contagem de referência em andamento.

4. Se sua classe se inscrever em eventos usando referências fortes. Você precisa cancelar o registro / desanexar-se dos eventos. Sempre verifique se eles não são nulos antes de tentar cancelar o registro / desanexação deles !.

5. Sua classe contém qualquer combinação dos itens acima ...

Uma alternativa recomendada para trabalhar com objetos COM e ter que usar Marshal.ReleaseComObject () é usar a classe System.Runtime.InteropServices.SafeHandle.

A BCL (Equipe da Biblioteca de Classes Base) tem uma boa publicação no blog aqui http://blogs.msdn.com/bclteam/archive/2005/03/16/396900.aspx

Uma observação muito importante a ser feita é que, se você estiver trabalhando com o WCF e limpando recursos, SEMPRE SEMPRE evite o bloco 'using'. Existem muitas postagens no blog e algumas no MSDN sobre por que essa é uma má idéia. Também publiquei aqui - Não use 'using ()' com um proxy WCF

Usando lambdas em vez de IDisposable.

Eu nunca fiquei empolgado com a ideia usando / IDisposable. O problema é que exige que o chamador:

• sabem que eles devem usar IDisposable
• lembre-se de usar 'using'.

Meu novo método preferido é usar um método de fábrica e um lambda

Imagine que eu quero fazer algo com um SqlConnection (algo que deve ser envolvido em um uso). Classicamente você faria

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

Nova maneira

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

No primeiro caso, o chamador simplesmente não pôde usar a sintaxe de uso. No segundo caso, o usuário não tem escolha. Não existe um método que crie um objeto SqlConnection, o chamador deve chamar DoWithConnection.

DoWithConnection se parece com isso

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

MakeConnection agora é privado

ninguém respondeu à pergunta sobre se você deve implementar o IDisposable, mesmo que não seja necessário.

Resposta curta: Não

Resposta longa:

Isso permitiria que um consumidor da sua classe usasse 'using'. A pergunta que eu faria é - por que eles fariam isso? A maioria dos desenvolvedores não usará 'using' a menos que saibam que precisam - e como sabem. Ou

• seus obviuos eles da experiência (uma classe de soquete, por exemplo)
• está documentado
• eles são cautelosos e podem ver que a classe implementa IDisposable

Portanto, ao implementar o IDisposable, você está dizendo aos desenvolvedores (pelo menos alguns) que essa classe encerra algo que deve ser lançado. Eles usarão 'using' - mas há outros casos em que o uso não é possível (o escopo do objeto não é local); e eles terão que começar a se preocupar com a vida útil dos objetos nesses outros casos - eu me preocuparia com certeza. Mas isso não é necessário

Você implementa Idisposable para permitir que eles usem usando, mas eles não usarão, a menos que você peça.

Então não faça isso

1. Se você estiver usando outros objetos gerenciados que estão usando recursos não gerenciados, não é sua responsabilidade garantir que eles sejam finalizados. Sua responsabilidade é chamar Dispose nesses objetos quando Dispose é chamado no seu objeto e para por aí.

2. Se sua classe não usa recursos escassos, não entendo por que você faria sua classe implementar IDisposable. Você só deve fazer isso se estiver:

   • Saiba que você terá recursos escassos em seus objetos em breve, mas não agora (e eu quero dizer que, como em "ainda estamos desenvolvendo, ele estará aqui antes de terminarmos", não como em "Acho que precisamos disso" ")
   • Usando recursos escassos

3. Sim, o código que usa seu código deve chamar o método Dispose do seu objeto. E sim, o código que usa seu objeto pode usar usingcomo você mostrou.

4. (2 novamente?) É provável que o WebClient use recursos não gerenciados ou outros recursos gerenciados que implementam IDisposable. A razão exata, no entanto, não é importante. O importante é que ele implemente o IDisposable e, portanto, você deve agir de acordo com esse conhecimento, descartando o objeto quando terminar, mesmo que o WebClient não utilize outros recursos.

Descarte o padrão:

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() { }
}

Exemplo de herança:

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

Alguns aspectos de outra resposta estão levemente incorretos por 2 razões:

Primeiro,

using(NoGateway objNoGateway = new NoGateway())

na verdade é equivalente a:

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

Isso pode parecer ridículo, pois o operador 'new' nunca deve retornar 'null', a menos que você tenha uma exceção OutOfMemory. Mas considere os seguintes casos: 1. Você chama um FactoryClass que retorna um recurso IDisposable ou 2. Se você possui um tipo que pode ou não herdar de IDisposable, dependendo de sua implementação - lembre-se de que eu vi o padrão IDisposable implementado incorretamente vezes em muitos clientes em que os desenvolvedores apenas adicionam um método Dispose () sem herdar de IDisposable (ruim, ruim, ruim). Você também pode ter o caso de um recurso IDisposable ser retornado de uma propriedade ou método (novamente ruim, ruim, ruim - não 'entregue seus recursos IDisposable)

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

Se o operador 'as' retornar nulo (ou propriedade ou método que retorna o recurso), e seu código no bloco 'using' proteger contra 'null', seu código não explodirá ao tentar chamar Dispose em um objeto nulo por causa de a verificação nula 'incorporada'.

A segunda razão pela qual sua resposta não é precisa é o seguinte stmt:

Um finalizador é chamado ao GC destruindo seu objeto

Primeiro, a finalização (assim como o próprio GC) não é determinística. O CLR determina quando chamará um finalizador. ou seja, o desenvolvedor / código não tem idéia. Se o padrão IDisposable for implementado corretamente (como postamos acima) e o GC.SuppressFinalize () tiver sido chamado, o Finalizador NÃO será chamado. Esse é um dos grandes motivos para implementar corretamente o padrão corretamente. Como existe apenas um encadeamento do Finalizer por processo gerenciado, independentemente do número de processadores lógicos, é possível degradar facilmente o desempenho fazendo backup ou até interrompendo o encadeamento do Finalizer, esquecendo de chamar GC.SuppressFinalize ().

Publiquei uma implementação correta do Dispose Pattern no meu blog: Como implementar corretamente o Dispose Pattern

1) O WebClient é um tipo gerenciado, portanto você não precisa de um finalizador. O finalizador é necessário no caso de seus usuários não Dispose () da sua classe NoGateway e o tipo nativo (que não é coletado pelo GC) precisa ser limpo depois. Nesse caso, se o usuário não chamar Dispose (), o WebClient contido será descartado pelo GC logo após o NoGateway.

2) Indiretamente sim, mas você não deve se preocupar com isso. Seu código está correto como está e você não pode impedir que seus usuários se esqueçam de Dispose () com muita facilidade.

Padrão do 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())

é equivalente a

try
{
    NoGateway = new NoGateway();
}

finally
{
    NoGateway.Dispose();
}

Um finalizador é chamado para o GC destruindo seu objeto. Isso pode ocorrer em um momento totalmente diferente do que quando você sai do seu método. O Dispose of IDisposable é chamado imediatamente depois que você sai do bloco using. Portanto, o padrão geralmente é usar o recurso para liberar recursos imediatamente após você não precisar mais deles.

Pelo que sei, é altamente recomendável NÃO usar o Finalizador / Destrutor:

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

Principalmente, isso se deve ao não saber quando ou se será chamado. O método de descarte é muito melhor, especialmente se você estiver usando ou descartado diretamente.

usando é bom. use-o :)