Quando devo criar um destruidor?

Por exemplo:

public class Person
{
    public Person()
    {
    }

    ~Person()
    {
    }
}

Quando devo criar manualmente um destruidor? Quando você precisou criar um destruidor?

ATUALIZAÇÃO: Esta questão foi o assunto do meu blog em maio de 2015 . Obrigado pela ótima pergunta! Veja o blog para uma longa lista de falsidades nas quais as pessoas geralmente acreditam em finalização.

Quando devo criar manualmente um destruidor?

Quase nunca.

Normalmente, só se cria um destruidor quando sua classe está segurando um recurso não gerenciado caro que deve ser limpo quando o objeto desaparecer. É melhor usar o padrão descartável para garantir que o recurso seja limpo. Um destruidor é então essencialmente uma garantia de que, se o consumidor do seu objeto esquecer de descartá-lo, o recurso ainda será limpo eventualmente. (Talvez.)

Se você criar um destruidor, seja extremamente cuidadoso e entenda como o coletor de lixo funciona . Destrutores são realmente estranhos :

• Eles não são executados no seu segmento; eles executam em seu próprio segmento. Não cause impasses!
• Uma exceção não tratada lançada de um destruidor é uma má notícia. Está em seu próprio segmento; quem vai pegá-lo?
• Um destruidor pode ser chamado em um objeto após o construtor iniciar, mas antes que o construtor termine. Um destruidor corretamente escrito não dependerá de invariantes estabelecidos no construtor.
• Um destruidor pode "ressuscitar" um objeto, dando vida a um objeto morto novamente. Isso é realmente estranho. Não faça isso.
• Um destruidor pode nunca ser executado; você não pode confiar no objeto que está sendo agendado para finalização. Ele provavelmente vai ser, mas isso não é uma garantia.

Quase nada que é normalmente verdadeiro é verdadeiro em um destruidor. Tenha muito, muito cuidado. Escrever um destruidor correto é muito difícil.

Quando você precisou criar um destruidor?

Ao testar a parte do compilador que lida com destruidores. Eu nunca precisei fazer isso no código de produção. Raramente escrevo objetos que manipulam recursos não gerenciados.

É chamado de "finalizador", e você normalmente deve criar apenas um para uma classe cujo estado (por exemplo: campos) inclua recursos não gerenciados (por exemplo: ponteiros para identificadores recuperados por meio de chamadas p / invoke). No entanto, no .NET 2.0 e posterior, há realmente uma maneira melhor de lidar com a limpeza de recursos não gerenciados: SafeHandle . Dado isso, você praticamente nunca precisará escrever um finalizador novamente.

Você não precisa de um, a menos que sua classe mantenha recursos não gerenciados, como identificadores de arquivo do Windows.

É chamado de destruidor / finalizador e geralmente é criado ao implementar o padrão Disposed.

É uma solução alternativa quando o usuário da sua classe se esquece de chamar Dispose, para garantir que (eventualmente) seus recursos sejam liberados, mas você não tem garantia de quando o destruidor é chamado.

Nesta questão do estouro de pilha , a resposta aceita mostra corretamente como implementar o padrão de descarte. Isso é necessário apenas se sua classe contiver recursos não manipulados que o coletor de lixo não conseguir limpar sozinho.

Uma boa prática é não implementar um finalizador sem também dar ao usuário da classe a possibilidade de Dispor manualmente o objeto para liberar os recursos imediatamente.

Quando você possui recursos não gerenciados e precisa garantir que eles sejam limpos quando o seu objeto desaparecer. Um bom exemplo seria objetos COM ou manipuladores de arquivos.

Eu usei um destruidor (apenas para fins de depuração) para verificar se um objeto estava sendo removido da memória no escopo de um aplicativo WPF. Eu não tinha certeza se a coleta de lixo estava realmente limpando o objeto da memória, e essa era uma boa maneira de verificar.

Os destruidores fornecem uma maneira implícita de liberar recursos não gerenciados encapsulados em sua classe, são chamados quando o GC o aborda e chamam implicitamente o método Finalize da classe base. Se você estiver usando muitos recursos não gerenciados, é melhor fornecer uma maneira explícita de liberar esses recursos por meio da interface IDisposable. Consulte o guia de programação em C #: http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx