Memory Leak: Quando um vazamento de memória pode derrubar a sua aplicação

Introdução

Vazamentos de memória são problemas silenciosos e cumulativos em sistemas complexos. Eles consomem memória gradualmente, degradando performance e eventualmente causando falhas críticas.

Embora sejam frequentemente associados a linguagens sem Garbage Collector (GC) ou coletor de lixo, como C e C++, .NET e Java que tem GC também são vulneráveis.

Python, Ruby, Go e JavaScript (Node.js) apresentam problemas semelhantes, principalmente em long-running processes e aplicações de alta concorrência.

Neste artigo, exploramos fundamentos, diagnóstico avançado, um caso real com Entity Framework, interações com código nativo via DllImport, uso de unsafe code, e estratégias de prevenção, com foco no ecossistema .NET.

Fundamentos do Gerenciamento de Memória no .NET

O Garbage Collector (GC) do .NET organiza a memória em Gen0, Gen1 e Gen2. Objetos curtos vivem em Gen0; se sobrevivem, promovem-se para Gen1 e Gen2. Objetos persistentes ou grandes permanecem na Gen2, tornando a coleta mais cara e menos frequente.

O Large Object Heap (LOH) armazena objetos acima de 85 kB e não é compactado frequentemente. Vazamentos no LOH causam fragmentação e degradação de desempenho.

É importante considerar que a coleta de lixo pode introduzir pausas na aplicação, especialmente ao coletar objetos da Gen2 e LOH. Essas pausas podem impactar a responsividade de aplicações críticas e long-running, reforçando a importância de um design de memória eficiente e do gerenciamento adequado de referências.

Não Interfira no Garbage Collector

Embora seja tecnicamente possível forçar a coleta de lixo com GC.Collect(), esta prática não resolve a causa raiz de um memory leak e pode prejudicar a performance geral do sistema. O uso de chamadas manuais ao GC deve ser evitado, pois não substitui uma análise detalhada da memória e correção dos padrões de vazamento.

A abordagem correta é identificar e eliminar referências desnecessárias, desinscrever eventos, implementar Dispose de maneira adequada e projetar caches de forma eficiente e controlada. Forçar a coleta do GC é apenas uma medida paliativa e não oferece garantia de estabilidade ou redução real do consumo de memória.

Como um Memory Leak Surge

Vazamentos ocorrem quando objetos permanecem referenciados sem necessidade. O GC não falha, mas objetos referenciados não são coletados.

Exemplos de Memory Leak em .NET

Eventos Não Desinscritos

publisher.SomeEvent += subscriber.Handle;
// subscriber nunca será coletado se não remover o handler

Closures Capturando Variáveis Externas

var cache = new List<Data>();
Action add = () => cache.Add(new Data());
// 'cache' permanece vivo enquanto 'add' existir

Caches Sem Expiração

static readonly Dictionary<string, object> _cache = new();
// Cresce indefinidamente se não houver remoção periódica

Uso Incorreto de HttpClient

// Errado: criar novo HttpClient a cada requisição
using var client = new HttpClient();

// Correto: HttpClientFactory
var client = httpClientFactory.CreateClient("MyClient");

Memory Leak em Código Unsafe

Em unsafe code, o desenvolvedor deve liberar memória manualmente. Objetos alocados com Marshal.AllocHGlobal permanecem até liberação explícita.

unsafe
{
    byte* buffer = (byte*)Marshal.AllocHGlobal(1024);
    // processamento
    // Marshal.FreeHGlobal(buffer); // esquecido: vazamento
}

Ferramentas como dotMemory, WinDbg e PerfView ajudam a identificar vazamentos nativos.

Memory Leak com Código Não Gerenciado

Ao usar [DllImport] para chamar bibliotecas nativas, a responsabilidade de liberar memória é do desenvolvedor.

[DllImport("kernel32.dll")]
public static extern IntPtr LocalAlloc(uint uFlags, UIntPtr uBytes);

[DllImport("kernel32.dll")]
public static extern IntPtr LocalFree(IntPtr hMem);

IntPtr ptr = LocalAlloc(0, (UIntPtr)1024);
// LocalFree(ptr); // se esquecido: vazamento nativo

Caso Real: GetMetadataWorkspace do Entity Framework

Em uma aplicação distribuída, foi identificado aumento contínuo de memória em produção, mesmo com carga estável. O profiling revelou que o vazamento estava relacionado ao Entity Framework, especificamente nas chamadas a GetMetadataWorkspace() de contextos dinâmicos.

Cada requisição criava internamente novos objetos de metadados, incluindo tipos, propriedades e relações do modelo. Esses objetos eram volumosos e mantidos na memória porque o EF armazenava referências internas, mesmo sem uso subsequente. O crescimento do heap era progressivo, saturando a Gen2 e o LOH, degradando performance e aumentando pressão do GC.

A solução foi implementar cache explícito para os metadados, usando GetItems<EntityType>(DataSpace.CSpace) para acessar os tipos de entidade e evitar recriações repetitivas. As caches tinham tamanho finito e, por isso, não necessitavam de política de expiração.

private static readonly ConcurrentDictionary<Type, MetadataWorkspace> _metadataCache = new();
private static readonly ConcurrentDictionary<Type, IReadOnlyCollection<EntityType>> _entityTypesCache = new();

public static MetadataWorkspace GetCachedMetadata(Type contextType)
{
    return _metadataCache.GetOrAdd(contextType, _ =>
    {
        using var ctx = (DbContext)Activator.CreateInstance(contextType);
        return ctx.ObjectContext.MetadataWorkspace;
    });
}

public static IReadOnlyCollection<EntityType> GetCachedEntityTypes(Type contextType)
{
    return _entityTypesCache.GetOrAdd(contextType, _ =>
    {
        var metadata = GetCachedMetadata(contextType);
        return metadata.GetItems<EntityType>(DataSpace.CSpace).ToList().AsReadOnly();
    });
}

Com isso, o consumo de memória estabilizou, evitando a criação repetitiva de objetos de metadados e garantindo reutilização dos tipos de entidade. Este caso evidencia que mesmo frameworks maduros podem apresentar vazamentos quando recursos internos não são gerenciados adequadamente.

Memory Leak Também em Outras Linguagens

Além de C# e Java, problemas similares são observados em:

• C/C++: vazamentos clássicos por falha de free ou delete.
• Python: referências circulares e caches globais.
• Ruby: closures e blocos mantendo referências.
• Go: Goroutines não finalizadas e slices persistentes.
• JavaScript/Node.js: closures, listeners e objetos globais.

O padrão é conceitual: o GC coleta apenas objetos sem referência direta. Aplicações long-running são especialmente sensíveis.

Diagnóstico e Ferramentas para .NET

Estratégia recomendada:

1. Reproduza a situação.
2. Capture snapshots em diferentes estágios.
3. Compare objetos e referências entre snapshots.
4. Identifique árvores de objetos persistentes.
5. Corrija padrões de vazamento, dispose, caches e eventos.

Boas Práticas para Evitar Vazamentos

• Implemente IDisposable corretamente.
• Desinscreva eventos em Dispose.
• Utilize caches com expiração e limitação de tamanho.
• Monitore métricas de heap, GC e alocação com Application Insights, Prometheus ou OpenTelemetry.
• Analise periodicamente com profilers mesmo sem incidentes.
• Evite closures e capturas desnecessárias.
• Prefira reuso de objetos pesados.

Conclusão

Memory leaks são silenciosos, traiçoeiros e podem comprometer aplicações críticas.

Em C# e outras linguagens, eles surgem por má gestão de referências e ciclo de vida de objetos.

Sistemas resilientes dependem de gestão consciente de memória.

Pequenos descuidos, como:

• eventos não limpos.
• caches mal desenhados.
• referências persistentes.

Podem derrubar aplicações.

O arquiteto deve garantir que a memória do sistema esteja tão saudável quanto o código que a utiliza.