Garbage collector no .NET: meça antes de ajustar

Pausas curtas que se acumulam

As coletas de geração 0 e geração 1 sempre bloqueiam as threads da aplicação, mas costumam ser rápidas. Já o background GC vale apenas para coletas de geração 2, que fazem boa parte do trabalho em uma thread dedicada.

Uma pausa curta raramente causa problema. Porém, quando um caminho muito acessado aloca rápido demais, as coletas pequenas se repetem e o tempo somado chega a ser percebido pelo usuário.

Por isso, reduzir a taxa de alocação costuma ajudar mais do que trocar uma configuração. Afinal, a contagem de coletas sozinha não diz quanto tempo o usuário esperou.

Comparando duas estratégias de buffer

O exemplo a seguir compara criar um buffer de 1 KB a cada iteração com criar um único buffer e reutilizá-lo. Além disso, cada método roda uma vez antes da medição, para que a primeira execução não distorça o resultado.

using System;

var allocationBytes = Measure(AllocateEachTime);
var reuseBytes = Measure(ReuseBuffer);

Console.WriteLine($"New buffer per item    {allocationBytes,15:N0}");
Console.WriteLine($"Reuse one buffer       {reuseBytes,15:N0}");

long Measure(Func<int> operation)
{
    _ = operation(); // aquecimento
    var before = GC.GetAllocatedBytesForCurrentThread();
    _ = operation();
    return GC.GetAllocatedBytesForCurrentThread() - before;
}

int AllocateEachTime()
{
    var total = 0;
    for (var i = 0; i < 500; i++)
    {
        var buffer = new byte[1024]; // novo array a cada volta
        buffer[0] = (byte)i;
        total += buffer[0];
    }

    return total;
}

int ReuseBuffer()
{
    var buffer = new byte[1024]; // um único array
    var total = 0;
    for (var i = 0; i < 500; i++)
    {
        buffer[0] = (byte)i;
        total += buffer[0];
    }

    return total;
}

Em um runtime de 64 bits, a primeira estratégia aloca 524.000 bytes e a segunda aloca apenas 1.048 bytes. Isso acontece porque cada byte[1024] ocupa 1.048 bytes no heap, somando os 24 bytes de cabeçalho, ponteiro de tipo e tamanho do array.

Os números podem variar um pouco entre versões do runtime. Mesmo assim, a diferença importa, porque são 499 arrays a menos para o garbage collector no .NET limpar.

Vale lembrar que esse método conta apenas o que a thread atual alocou. Ele não mostra a memória ainda em uso nem o consumo do processo inteiro, então comparações sérias pedem uma ferramenta como o BenchmarkDotNet.

Observando o garbage collector no .NET em produção

Com a aplicação rodando, os contadores do runtime mostram o comportamento real. Entre os valores úteis estão a taxa de alocação, o tamanho do heap gerenciado, a frequência de coletas de geração 2 e o tempo gasto em GC.

# instala a ferramenta, se necessário
dotnet tool install --global dotnet-counters

# troque 1234 pelo id do processo
dotnet-counters monitor --process-id 1234 System.Runtime

Esses contadores mostram a atividade geral do garbage collector no .NET, mas não a duração de cada pausa. Para isso, você coleta um trace enquanto a aplicação processa uma carga representativa.

dotnet tool install --global dotnet-trace
dotnet-trace collect --process-id 1234 --profile gc-collect

O perfil gc-collect registra apenas eventos de coleta, então o overhead é muito baixo. Em seguida, você abre o trace no PerfView e inspeciona os eventos de pausa.

Quando precisar também de eventos de alocação amostrados, o perfil gc-verbose atende, com um custo maior. Já o impacto real na latência das requisições aparece em testes de carga ou na telemetria de produção.

Span, stackalloc e ArrayPool

Quando a medição aponta um trecho crítico, stackalloc com Span<T> funciona bem para buffers pequenos e de vida curta. O método abaixo monta um código de pedido na pilha e aloca somente a string final.

static string FormatOrderCode(int id)
{
    Span<char> chars = stackalloc char[16]; // buffer na pilha
    "ORD-".AsSpan().CopyTo(chars);
    id.TryFormat(chars[4..], out var written);
    return new string(chars[..(4 + written)]); // única alocação no heap
}

Para arrays maiores, o ArrayPool<T> empresta um array de um pool compartilhado. Assim, a próxima chamada reaproveita o mesmo array, e o garbage collector no .NET não limpa um array novo a cada uso.

using System.Buffers;

static int ChecksumOfLength(int length)
{
    var buffer = ArrayPool<byte>.Shared.Rent(length);
    try
    {
        var data = buffer.AsSpan(0, length); // Rent pode devolver um array maior
        for (var i = 0; i < data.Length; i++)
        {
            data[i] = (byte)i;
        }

        var sum = 0;
        foreach (var value in data)
        {
            sum += value;
        }

        return sum;
    }
    finally
    {
        ArrayPool<byte>.Shared.Return(buffer); // devolve mesmo em caso de erro
    }
}

O método Rent pode devolver um array maior que o pedido, por isso o código fatia o trecho necessário. Além disso, o array não deve ser usado depois de devolvido, e buffers com stackalloc precisam ser pequenos, porque o espaço na pilha é limitado.

StringBuilder para concatenações repetidas

Strings no C# não mudam depois de criadas. Logo, concatenar com + dentro de um laço pode gerar uma string intermediária a cada volta, e todas viram trabalho para o garbage collector no .NET.

using System.Text;

var parts = new[] { "GC", " ", "measures", " ", "memory" };
var builder = new StringBuilder();

foreach (var part in parts)
{
    builder.Append(part); // reaproveita o buffer interno
}

var message = builder.ToString();

O StringBuilder também aloca o próprio objeto e a string final. Portanto, ele compensa em anexos repetidos, enquanto poucas partes fixas ficam mais claras com a concatenação comum.

Dispose e o padrão de descarte

O IDisposable expõe um método Dispose para liberar recursos em um momento previsível. Chamar Dispose não manda o garbage collector no .NET coletar o objeto, apenas libera o que ele possui.

using System.IO;

using (var stream = File.OpenRead("report.json"))
{
    // leia o arquivo aqui
}

// o Dispose já rodou, então o handle pode ser liberado

O compilador transforma o bloco using em um try/finally que chama Dispose. Dessa forma, o recurso é liberado mesmo quando ocorre uma exceção.

Uma classe que só possui outros objetos descartáveis não precisa de finalizador. O finalizador só entra em cena quando a classe guarda diretamente um recurso não gerenciado.

using System;
using System.Runtime.InteropServices;

public class NativeScratchBuffer : IDisposable
{
    private IntPtr _memory;
    private bool _disposed;

    public NativeScratchBuffer(int sizeInBytes) =>
        _memory = Marshal.AllocHGlobal(sizeInBytes);

    ~NativeScratchBuffer() => Dispose(disposing: false);

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this); // evita manter o objeto vivo para a finalização
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed)
            return;

        if (disposing)
        {
            // descarte aqui os objetos gerenciados que a classe possui
        }

        if (_memory != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(_memory);
            _memory = IntPtr.Zero;
        }

        _disposed = true;
    }
}

O GC.SuppressFinalize também tem efeito na performance. Isso porque um objeto que ainda precisa de finalização vai para a fila do finalizador e continua vivo, com tudo o que referencia, até uma coleta posterior.

Em código real, prefira SafeHandle para envolver handles do sistema operacional. Ele já oferece uma limpeza confiável quando o Dispose é esquecido.

Eventos, timers e referências fracas

Eventos também mantêm objetos vivos. Quando um objeto assina o evento de outro, o publicador guarda uma referência ao assinante até que ele cancele a assinatura.

public sealed class PriceBadge : IDisposable
{
    private readonly StockTicker _ticker;

    public PriceBadge(StockTicker ticker)
    {
        _ticker = ticker;
        _ticker.PriceChanged += OnPriceChanged;
    }

    // cancela a assinatura para o badge poder ser coletado
    public void Dispose() => _ticker.PriceChanged -= OnPriceChanged;

    private void OnPriceChanged(object? sender, decimal price) =>
        Console.WriteLine($"Badge shows {price}");
}

Se um StockTicker de vida longa receber milhares de assinaturas sem Dispose, cada badge continua na lista de handlers. Ou seja, há um vazamento de memória, mesmo que o código não use mais esses objetos.

Timers prendem objetos de modo parecido, fora do alcance do garbage collector no .NET. Um System.Timers.Timer iniciado é mantido vivo pela infraestrutura de timers do runtime, por isso você deve pará-lo, remover o handler de Elapsed e descartá-lo.

Já o WeakReference<T> aponta para um objeto sem mantê-lo vivo. Assim, ele serve para um cache opcional, cujo conteúdo pode ser recriado se o GC já tiver coletado o alvo.

No entanto, referência fraca não substitui o Dispose, a parada de um timer ou o cancelamento de um evento. Essas tarefas pedem posse explícita e limpeza explícita.

Modos do garbage collector no .NET

O workstation GC foi pensado para aplicações que dividem a máquina com outros programas. Por isso, ele usa orçamentos de alocação menores, coleta com mais frequência e mantém a memória mais baixa.

O server GC, por sua vez, trata a aplicação como a carga principal da máquina. Por padrão, ele cria um heap e uma thread de GC por CPU lógica, então costuma processar mais trabalho e usar mais memória.

<PropertyGroup>
  <!-- liga o server GC no arquivo de projeto -->
  <ServerGarbageCollection>true</ServerGarbageCollection>
</PropertyGroup>

Aplicações ASP.NET Core usam server GC por padrão, enquanto apps de console, desktop e workers usam workstation GC. Mesmo assim, nenhum dos modos é sempre mais rápido, então teste os dois com a carga real.

O DATAS, sigla de Dynamic Adaptation to Application Sizes, tenta manter o heap proporcional aos dados de vida longa da aplicação. Ele começa com um único heap e adiciona ou remove heaps conforme a carga muda.

O recurso surgiu como opcional no .NET 8 e passou a ser padrão no server GC a partir do .NET 9. A documentação oficial do DATAS explica que ele troca um pouco de throughput por um working set bem menor.

<PropertyGroup>
  <ServerGarbageCollection>true</ServerGarbageCollection>
  <!-- desliga o DATAS apenas se a medição mostrar perda de throughput -->
  <GarbageCollectionAdaptationMode>0</GarbageCollectionAdaptationMode>
</PropertyGroup>

Mesmo assim, o DATAS não é um teto rígido de memória. Em um container com limite, o limite padrão do heap do GC é 75% desse valor, mas ele não cobre a memória nativa do processo.

Compactação do LOH e regiões sem GC

Objetos com 85.000 bytes ou mais vão para o LOH e são coletados junto com a geração 2. Por padrão, o garbage collector no .NET deixa lacunas onde ficavam objetos grandes mortos, em vez de copiar blocos enormes de memória.

Se o profiling mostrar que essas lacunas causam problema, você pode pedir uma compactação única. O pedido vale para a próxima coleta completa e bloqueante, e depois a configuração volta para Default.

using System.Runtime;

GCSettings.LargeObjectHeapCompactionMode =
    GCLargeObjectHeapCompactionMode.CompactOnce;

// opcional: compacta agora, em um momento controlado
GC.Collect();

Force a coleta apenas em momentos controlados, como o fim de um job em lote. Além disso, confirme antes que a fragmentação do LOH é realmente o problema.

Já uma região sem GC é um período curto em que o runtime tenta não iniciar coletas. O método GC.TryStartNoGCRegion reserva um orçamento de memória e pode falhar se não conseguir reservá-lo.

using System.Runtime;

const long budgetBytes = 32 * 1024 * 1024;

if (GC.TryStartNoGCRegion(budgetBytes))
{
    try
    {
        ProcessAudioBlock(); // trabalho curto e limitado
    }
    finally
    {
        // a região pode ter terminado antes se o orçamento estourou
        if (GCSettings.LatencyMode == GCLatencyMode.NoGCRegion)
            GC.EndNoGCRegion();
    }
}
else
{
    ProcessAudioBlock();
}

Se a aplicação passar do orçamento, o runtime encerra a região antes. Nesse caso, chamar GC.EndNoGCRegion() lança InvalidOperationException, por isso o código verifica o modo de latência primeiro.

Use esse recurso apenas para trabalhos curtos e medidos, como um bloco de áudio em tempo real. Na maioria das aplicações, reduzir alocações é uma escolha mais simples e mais segura.