Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Observação
Este artigo fornece observações complementares à documentação de referência para esta API.
A GC classe controla o coletor de lixo. O coletor de lixo é um componente do tempo de execução de uma linguagem comum que controla a alocação e liberação de memória gerida. Os métodos nessa classe influenciam quando a coleta de lixo é executada em um objeto e quando os recursos alocados por um objeto são liberados. As propriedades nesta classe fornecem informações sobre a quantidade total de memória disponível no sistema e a categoria etária, ou geração, de memória alocada a um objeto.
O coletor de lixo rastreia e recupera objetos alocados na memória gerenciada. Periodicamente, o coletor de lixo realiza a coleta de lixo para recuperar a memória alocada a objetos para os quais não há referências válidas. A coleta de lixo acontece automaticamente quando uma solicitação de memória não pode ser satisfeita usando a memória livre disponível. Como alternativa, um aplicativo pode forçar a coleta de lixo usando o Collect método.
A recolha de lixo consiste nos seguintes passos:
- O coletor de lixo procura objetos gerenciados que são referenciados no código gerenciado.
- O coletor de lixo tenta finalizar objetos que não são referenciados.
- O coletor de lixo libera objetos que não são referenciados e recupera sua memória.
Recursos não geridos
Durante uma coleta, o coletor de lixo não liberará um objeto se encontrar uma ou mais referências ao objeto no código gerenciado. No entanto, o coletor de lixo não reconhece referências a um objeto a partir de código não gerenciado e pode liberar objetos que estão a ser usados exclusivamente em código não gerenciado, a menos que esteja explicitamente prevenido de fazê-lo. O KeepAlive método fornece um mecanismo que impede que o coletor de lixo colete objetos que ainda estão em uso em código não gerenciado.
Exceto em relação às alocações de memória gerenciada, as implementações do coletor de lixo não mantêm informações sobre os recursos que um objeto possui, como identificadores de arquivos ou conexões de banco de dados. Quando um tipo usa recursos não gerenciados que devem ser liberados antes que instâncias do tipo sejam recuperadas, o tipo pode implementar um finalizador.
Na maioria dos casos, os finalizadores são implementados substituindo o método Object.Finalize; no entanto, os tipos escritos em C# ou C++ implementam destrutores, que os compiladores transformam em uma substituição para Object.Finalize. Na maioria dos casos, se um objeto tiver um finalizador, o coletor de lixo o chamará antes de liberar o objeto. No entanto, o coletor de lixo não é obrigado a chamar finalizadores em todas as situações; por exemplo, o método SuppressFinalize impede explicitamente que o finalizador de um objeto seja chamado. Além disso, o coletor de lixo não é obrigado a usar um thread específico para finalizar objetos, ou garantir a ordem em que os finalizadores são chamados para objetos que fazem referência uns aos outros, mas estão disponíveis para coleta de lixo.
Em cenários em que os recursos devem ser liberados em um momento específico, as classes podem implementar a IDisposable interface, que contém o IDisposable.Dispose método que executa tarefas de gerenciamento e limpeza de recursos. As classes que implementam Dispose devem especificar, como parte do seu contrato de classe, se e quando os utilizadores da classe chamam o método para limpar o objeto. O coletor de lixo não chama, por padrão, o Dispose método, no entanto, as Dispose implementações do método podem chamar métodos na GC classe para personalizar o comportamento de finalização do coletor de lixo.
Para obter mais informações sobre a finalização de objetos e o padrão de descarte, consulte Limpando recursos não gerenciados.
Envelhecimento de objetos e gerações
O coletor de lixo no Common Language Runtime suporta o envelhecimento de objetos usando gerações. Uma geração é uma unidade de medida da idade relativa dos objetos na memória. O número de geração, ou idade, de um objeto indica a geração à qual um objeto pertence. Os objetos criados mais recentemente fazem parte das gerações mais recentes e têm números de geração mais baixos do que os objetos criados anteriormente no ciclo de vida do aplicativo. Os objetos da geração mais recente estão na geração 0. Esta implementação do coletor de lixo suporta três gerações de objetos, gerações 0, 1 e 2. Você pode recuperar o valor da propriedade para determinar o número máximo de geração suportado MaxGeneration pelo sistema.
O envelhecimento de objetos permite que os aplicativos direcionem a coleta de lixo para um conjunto específico de gerações, em vez de exigir que o coletor de lixo avalie todas as gerações. As sobrecargas do Collect método que incluem um generation parâmetro permitem que especifique a geração mais antiga sujeita à recolha de lixo.
Não permitir a recolha de lixo
O coletor de lixo suporta um modo de latência de região sem GC que é utilizado durante a execução de caminhos críticos nos quais a coleta de lixo afeta negativamente o desempenho de uma aplicação. O modo de latência sem região GC requer que você especifique uma quantidade de memória que pode ser alocada sem interferência do coletor de lixo. Se o tempo de execução puder alocar essa memória, o tempo de execução não executará uma coleta de lixo enquanto o código no caminho crítico estiver em execução.
Você define o início do caminho crítico da região sem GC chamando uma das sobrecargas do TryStartNoGCRegion. Você especifica o final de seu caminho crítico chamando o EndNoGCRegion método.
Não é possível aninhar chamadas para o TryStartNoGCRegion método e você só deve chamar o EndNoGCRegion método se o tempo de execução estiver atualmente em nenhum modo de latência de região GC. Em outras palavras, você não deve ligar TryStartNoGCRegion várias vezes (após a primeira chamada de método, as chamadas subsequentes não terão êxito), e você não deve esperar que as chamadas EndNoGCRegion sejam bem-sucedidas apenas porque a primeira chamada foi TryStartNoGCRegion bem-sucedida.