C# Memória e Coletor de Lixo

Todo new que você escreve pede um pedaço da memória do computador: uma lista de compras, um texto, um objeto Conta. Em linguagens como o C, o programador tem de devolver cada pedaço com free, e esquecer disso é um dos erros mais comuns. Em C# quem devolve é o coletor de lixo (em inglês, garbage collector, ou GC). Nesta aula você vai ver onde as variáveis moram, quando um objeto vira "lixo", como o coletor trabalha e por que, mesmo com ele, um programa C# ainda pode gastar memória demais.

Os programas desta aula rodaram na máquina da Ana com o .NET 10, cada um num arquivo solto em ~/cs, com dotnet run arquivo.cs (veja Rodar com dotnet run). Para entender a aula, ajuda ter visto Valor × Referência e Classes e Objetos.

A ideia: a mesa, o depósito e o faxineiro

Imagine a lojinha da Ana. Ela trabalha numa mesa pequena, onde ficam só as coisas da tarefa do momento: a calculadora, um bloquinho. Quando a tarefa acaba, a mesa é limpa de uma vez. As caixas grandes ficam num depósito nos fundos, e na mesa ela guarda só um papelzinho com o endereço da caixa ("prateleira 7"). De vez em quando passa um faxineiro pelo depósito: toda caixa cujo endereço não está anotado em nenhum papel é jogada fora, porque ninguém mais consegue achá-la.

Os tipos de valor (int, double, decimal, bool, structs) guardam o próprio valor na variável. Os tipos de referência (string, arrays, List<T>, as suas classes) guardam um endereço, e o objeto fica no heap.

1. Uma cópia × o mesmo objeto

Este programa mostra as duas coisas lado a lado. Copiar um int copia o número. Copiar uma lista copia só o endereço: as duas variáveis passam a apontar para a mesma lista no heap.

int idade = 31;
int copia = idade;
copia = 40;
Console.WriteLine($"idade = {idade}, copia = {copia}");

var compras = new List<string> { "arroz" };
var mesmaLista = compras;
mesmaLista.Add("feijão");
Console.WriteLine($"compras tem {compras.Count} itens: {string.Join(", ", compras)}");
Console.WriteLine(ReferenceEquals(compras, mesmaLista));

$ dotnet run ref.cs
idade = 31, copia = 40
compras tem 2 itens: arroz, feijão
True

2. Quando um objeto vira lixo

O coletor não olha se o objeto "ainda vai ser usado" (isso ele não tem como saber). Ele olha se o objeto ainda é alcançável: se dá para chegar até ele partindo das variáveis locais dos métodos que estão rodando e dos campos static. Esses pontos de partida se chamam raízes. O que não é alcançável é lixo.

Para ver isso acontecer, usamos uma WeakReference ("referência fraca"): ela observa um objeto sem segurá-lo. Se só ela aponta para o objeto, o coletor pode levá-lo, e a propriedade IsAlive ("está vivo") passa a dar false.

using System.Runtime.CompilerServices;

WeakReference observador = CriarRelatorio();
Console.WriteLine($"Antes da coleta, vivo? {observador.IsAlive}");

GC.Collect();
Console.WriteLine($"Depois da coleta, vivo? {observador.IsAlive}");

[MethodImpl(MethodImplOptions.NoInlining)]
static WeakReference CriarRelatorio()
{
    var relatorio = new byte[1_000_000];
    return new WeakReference(relatorio);
}

static WeakReference CriarRelatorio()

Um método local que cria um array de 1 milhão de bytes (1 MB) e devolve só um observador dele. A variável relatorio é local: quando o método termina, ela some da pilha, e nenhuma referência "forte" ao array sobra.

[MethodImpl(MethodImplOptions.NoInlining)]

Um atributo que pede ao .NET para não "colar" o método dentro de quem o chama (inlining). Assim temos certeza de que relatorio morre quando o método volta. Num programa normal você não precisa disso; aqui é só para o experimento dar sempre o mesmo resultado.

GC.Collect()

Manda o coletor passar agora. Só usamos para aprender: num programa de verdade, deixe o .NET decidir (veja a dica mais abaixo).

observador.IsAlive

true enquanto o objeto existir.

$ dotnet run lixo.cs
Antes da coleta, vivo? True
Depois da coleta, vivo? False

Antes da coleta o array ainda existia (virou lixo, mas o faxineiro não tinha passado). Depois, o coletor viu que ninguém o alcançava e liberou o 1 MB.

byte[]? relatorio = new byte[1_000_000];
var observador = new WeakReference(relatorio);
relatorio = null;
GC.Collect();
Console.WriteLine($"Ainda vivo? {observador.IsAlive}");

$ dotnet run fraca.cs
Ainda vivo? True

3. Gerações: o coletor olha primeiro para os novatos

Varrer o depósito inteiro toda vez seria lento. O coletor do .NET aposta numa coisa que quase sempre é verdade: a maioria dos objetos morre jovem (um texto montado para um WriteLine, uma lista temporária). Por isso ele separa o heap em gerações:

var compras = new List<string> { "arroz", "feijão" };
Console.WriteLine($"Recém-criada: geração {GC.GetGeneration(compras)}");

GC.Collect();
Console.WriteLine($"Sobreviveu a 1 coleta: geração {GC.GetGeneration(compras)}");

GC.Collect();
Console.WriteLine($"Sobreviveu a 2 coletas: geração {GC.GetGeneration(compras)}");

Console.WriteLine($"Maior geração: {GC.MaxGeneration}");
Console.WriteLine($"Coletas da geração 0 até agora: {GC.CollectionCount(0)}");

GC.GetGeneration(compras)

Em que geração o objeto está agora.

GC.Collect()

Uma coleta completa. A lista ainda é usada (a variável compras a alcança), então sobrevive e é promovida para a geração seguinte.

GC.MaxGeneration

O número da última geração.

GC.CollectionCount(0)

Quantas vezes a geração 0 foi varrida desde que o programa começou. Toda coleta completa também conta como coleta da geração 0.

$ dotnet run geracoes.cs
Recém-criada: geração 0
Sobreviveu a 1 coleta: geração 1
Sobreviveu a 2 coletas: geração 2
Maior geração: 2
Coletas da geração 0 até agora: 2

4. Medir a memória

A classe GC tem dois métodos para espiar a memória:

• GC.GetTotalMemory(true): quantos bytes os objetos vivos ocupam agora no heap. O true pede uma coleta antes de medir, para não contar lixo.
• GC.GetAllocatedBytesForCurrentThread(): quantos bytes este programa já pediu desde o começo, contando o que já virou lixo. Serve para comparar duas formas de fazer a mesma coisa.

Um exemplo clássico: montar um texto de 1000 letras com += e com StringBuilder.

using System.Text;

long antes = GC.GetAllocatedBytesForCurrentThread();
string texto = "";
for (int i = 0; i < 1000; i++)
{
    texto += "x";
}
long depois = GC.GetAllocatedBytesForCurrentThread();
Console.WriteLine($"Com +=:           {depois - antes:N0} bytes");

antes = GC.GetAllocatedBytesForCurrentThread();
var sb = new StringBuilder();
for (int i = 0; i < 1000; i++)
{
    sb.Append('x');
}
string pronto = sb.ToString();
depois = GC.GetAllocatedBytesForCurrentThread();
Console.WriteLine($"Com StringBuilder: {depois - antes:N0} bytes");
Console.WriteLine(texto == pronto);

$ dotnet run aloc.cs
Com +=:           1.025.976 bytes
Com StringBuilder: 4.576 bytes
True

using System.Text;

long antes = GC.GetAllocatedBytesForCurrentThread();
string texto = "";
for (int i = 0; i < 1000; i++)
{
    texto += "x";
}
long depois = GC.GetAllocatedBytesForCurrentThread();
Console.WriteLine($"Com +=:           {depois - antes:N0} bytes");

antes = GC.GetAllocatedBytesForCurrentThread();
var sb = new StringBuilder();
for (int i = 0; i < 1000; i++)
{
    sb.Append('x');
}
string pronto = sb.ToString();
depois = GC.GetAllocatedBytesForCurrentThread();
Console.WriteLine($"Com StringBuilder: {depois - antes:N0} bytes");
Console.WriteLine(texto == pronto);

Os dois textos são iguais (True), mas o += pediu mais de 1 milhão de bytes, e o StringBuilder, menos de 5 mil. Por quê? Uma string nunca muda (ela é imutável). Cada texto += "x" cria uma string nova, uma letra maior, e a anterior vira lixo: 1000 strings de 1, 2, 3… até 1000 letras, cada letra com 2 bytes. O StringBuilder vai enchendo uma área que cresce aos poucos e só cria a string no fim.

5. "Vazamento" de memória em C#

Com o coletor, você nunca esquece de liberar um objeto que ninguém usa. Mas existe o problema contrário: um objeto que você não usa mais, mas que continua alcançável. O coletor não pode levá-lo. Se isso se repete, a memória só cresce: é o que se chama de vazamento em C#.

Uma lista static que só cresce

Campos static são raízes: vivem enquanto o programa viver. A Ana guardou os relatórios de cada dia num "cache" (uma lista para reaproveitar depois), mas nunca tirou nada de lá:

for (int dia = 1; dia <= 5; dia++)
{
    Relatorios.Gerar(dia);
}
Console.WriteLine($"Relatórios guardados: {Relatorios.Cache.Count}");
Console.WriteLine($"Memória: {GC.GetTotalMemory(true) / 1_000_000} MB");

static class Relatorios
{
    public static List<byte[]> Cache { get; } = new();

    public static void Gerar(int dia)
    {
        byte[] relatorio = new byte[10_000_000]; // 10 MB
        Cache.Add(relatorio);
        Console.WriteLine($"Dia {dia}: relatório gerado");
    }
}

$ dotnet run cache.cs
Dia 1: relatório gerado
Dia 2: relatório gerado
Dia 3: relatório gerado
Dia 4: relatório gerado
Dia 5: relatório gerado
Relatórios guardados: 5
Memória: 50 MB

A variável relatorio morre no fim de cada Gerar, mas a lista Cache continua segurando cada array. Cinco dias, 50 MB. Num programa que fica ligado o mês inteiro, seria 300 MB, depois 1 GB… O conserto é decidir quanto guardar: só os últimos dias, por exemplo.

for (int dia = 1; dia <= 5; dia++)
{
    Relatorios.Gerar(dia);
}
Console.WriteLine($"Relatórios guardados: {Relatorios.Cache.Count}");

static class Relatorios
{
    public static List<byte[]> Cache { get; } = new();

    public static void Gerar(int dia)
    {
        byte[] relatorio = new byte[1_000_000]; // 1 MB
        Cache.Add(relatorio);
        // se o cache passou de 3, tire o mais antigo
        Console.WriteLine($"Dia {dia}: relatório gerado");
    }
}

for (int dia = 1; dia <= 5; dia++)
{
    Relatorios.Gerar(dia);
}
Console.WriteLine($"Relatórios guardados: {Relatorios.Cache.Count}");

static class Relatorios
{
    public static List<byte[]> Cache { get; } = new();

    public static void Gerar(int dia)
    {
        byte[] relatorio = new byte[1_000_000]; // 1 MB
        Cache.Add(relatorio);
        if (Cache.Count > 3)
        {
            Cache.RemoveAt(0);
        }
        Console.WriteLine($"Dia {dia}: relatório gerado");
    }
}

Um evento sem -=

Quando um objeto se inscreve num evento com +=, o dono do evento passa a guardar uma referência a ele. Se ninguém fizer -=, o inscrito fica vivo enquanto o dono do evento viver, mesmo que mais ninguém o use. No exemplo abaixo, cada Tela é usada uma vez só, mas o Relogio continua chamando todas:

var relogio = new Relogio();
for (int i = 1; i <= 3; i++)
{
    var tela = new Tela($"Tela {i}");
    relogio.Tique += tela.Mostrar;
    relogio.Bater();
}
Console.WriteLine($"Inscritos no fim: {relogio.Inscritos}");

class Relogio
{
    public event Action? Tique;
    public int Inscritos => Tique?.GetInvocationList().Length ?? 0;
    public void Bater() => Tique?.Invoke();
}

class Tela(string nome)
{
    public void Mostrar() => Console.WriteLine($"{nome}: tique!");
}

$ dotnet run evento.cs
Tela 1: tique!
Tela 1: tique!
Tela 2: tique!
Tela 1: tique!
Tela 2: tique!
Tela 3: tique!
Inscritos no fim: 3

relogio.Tique += tela.Mostrar;

Inscreve o método Mostrar daquela tela. O evento guarda o método e o objeto tela.

Tique?.GetInvocationList().Length

Quantos métodos estão inscritos no evento.

class Tela(string nome)

Uma classe com construtor primário C# 12: o nome fica disponível dentro dela.

A "Tela 1" foi chamada três vezes, embora o laço já tenha passado dela: o relógio ainda a segura. Num programa com janelas, cada janela fechada continuaria na memória.

6. O coletor cuida da memória, não dos arquivos

Um objeto que abriu um arquivo ou uma conexão segura algo que não é memória: o arquivo fica aberto no sistema. O coletor não sabe disso e só passa quando acha que falta memória, o que pode demorar. Existe um jeito de rodar código quando o coletor leva um objeto, o finalizador (~NomeDaClasse()), mas você não controla quando ele roda:

using System.Runtime.CompilerServices;

UsarArquivo();
Console.WriteLine("Chamando o coletor...");
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("Fim do programa");

[MethodImpl(MethodImplOptions.NoInlining)]
static void UsarArquivo()
{
    var r = new Recurso("notas.txt");
    Console.WriteLine($"Usando {r.Nome}");
}

class Recurso
{
    public string Nome { get; }
    public Recurso(string nome) => Nome = nome;
    ~Recurso() => Console.WriteLine($"Finalizador: liberando {Nome}");
}

$ dotnet run final.cs
Usando notas.txt
Chamando o coletor...
Finalizador: liberando notas.txt
Fim do programa

O UsarArquivo terminou bem antes, mas o "arquivo" só foi liberado quando chamamos o coletor à força e esperamos os finalizadores (GC.WaitForPendingFinalizers). Sem essas duas linhas, ele poderia ficar aberto até o fim do programa. No editor do guia é ainda pior: lá o finalizador não chegou a rodar, e a linha Finalizador: … nem aparece. Por isso a regra do C#:

Qual usar: quando se preocupar com memória

Quando dá errado

int Contar(int n)
{
    return Contar(n + 1);
}

Console.WriteLine("Contando...");
Console.WriteLine(Contar(1));

$ dotnet run pilha.cs
Contando...
Stack overflow.
Repeated 261736 times:                    « o número muda um pouco a cada execução
--------------------------------
   at Program.<<Main>$>g__Contar|0_0(Int32)
--------------------------------
   at Program.<Main>$(System.String[])
$ echo $?
134

Console.WriteLine("Criando um array gigante...");
int[] numeros = new int[int.MaxValue];
Console.WriteLine(numeros.Length);

$ dotnet run oom.cs
Criando um array gigante...
Out of memory.
$ echo $?
134

try
{
    int[] numeros = new int[int.MaxValue];
    Console.WriteLine(numeros.Length);
}
catch (OutOfMemoryException e)
{
    Console.WriteLine(e.Message);
}

$ dotnet run oom2.cs
Array dimensions exceeded supported range.

Referência

Exercícios

var relogio = new Relogio();
for (int i = 1; i <= 3; i++)
{
    var tela = new Tela($"Tela {i}");
    relogio.Tique += tela.Mostrar;
    relogio.Bater();
}
Console.WriteLine($"Inscritos no fim: {relogio.Inscritos}");

class Relogio
{
    public event Action? Tique;
    public int Inscritos => Tique?.GetInvocationList().Length ?? 0;
    public void Bater() => Tique?.Invoke();
}

class Tela(string nome)
{
    public void Mostrar() => Console.WriteLine($"{nome}: tique!");
}

var relogio = new Relogio();
for (int i = 1; i <= 3; i++)
{
    var tela = new Tela($"Tela {i}");
    relogio.Tique += tela.Mostrar;
    relogio.Bater();
    relogio.Tique -= tela.Mostrar;
}
Console.WriteLine($"Inscritos no fim: {relogio.Inscritos}");

class Relogio
{
    public event Action? Tique;
    public int Inscritos => Tique?.GetInvocationList().Length ?? 0;
    public void Bater() => Tique?.Invoke();
}

class Tela(string nome)
{
    public void Mostrar() => Console.WriteLine($"{nome}: tique!");
}

$ dotnet run evento.cs                     « com o -=
Tela 1: tique!
Tela 2: tique!
Tela 3: tique!
Inscritos no fim: 0

Resumo

• Variáveis locais ficam na pilha e somem quando o método termina; objetos criados com new ficam no heap.
• Uma variável de tipo de referência guarda o endereço do objeto; copiar a variável copia o endereço.
• O coletor de lixo libera os objetos que nenhuma raiz alcança, numa hora que ele escolhe.
• O heap tem gerações: 0 (novos), 1 e 2 (vida longa). A maioria dos objetos morre na geração 0, onde a coleta é barata.
• += em string num laço gera muito lixo; StringBuilder resolve.
• Vazamento em C# é objeto inútil mas alcançável: listas static sem limite e eventos sem -=.
• O coletor cuida só da memória; arquivos e conexões se fecham com using.
• Stack overflow. é recursão sem fim; Out of memory. é um pedido grande demais. Os dois encerram o programa com o código 134.

Próxima aula: Boas Práticas.