Gerenciamento de memória

Onde os dados moram: pilha e heap

Um programa guarda os seus dados em duas regiões de memória com regras diferentes:

Quase tudo o que importa num backend mora no heap: os pedidos recebidos, as respostas montadas, os resultados das consultas, os caches. É no heap que a memória acaba.

Quem libera a memória

Em C e C++, o programador reserva e libera a memória à mão. Esquecer de liberar vaza memória; liberar duas vezes ou usar algo já liberado corrompe o programa e abre falhas de segurança.

As cinco linguagens desta trilha usam um coletor de lixo (garbage collector): o runtime descobre sozinho quais objetos não são mais usados e libera a memória deles.

A regra do coletor: o que é alcançável fica

O coletor não sabe se um objeto ainda vai ser usado. Ele sabe se o objeto ainda é alcançável: se existe um caminho de referências partindo das variáveis globais, das variáveis locais em uso ou de outras raízes até ele.

raízes (variáveis globais, pilhas das threads)
   │
   ├──▶ cache global ──▶ usuário 1 ──▶ perfil
   │                 ──▶ usuário 2 ──▶ perfil      ← alcançáveis: ficam
   │
   └──▶ pedido atual ──▶ resposta

   objeto de um pedido que já terminou             ← inalcançável: é coletado

Isso explica a forma dos vazamentos em linguagens com coletor: uma referência esquecida num lugar que dura para sempre. O objeto nunca mais será usado, mas um mapa global ainda aponta para ele, e o coletor é obrigado a mantê-lo.

De onde vêm os vazamentos

O mais comum é o primeiro. Medimos com um cache em Node que guardava o perfil de cada usuário novo, num container de 512 MB:

Com tráfego real, o cache sem limite leva dias para encher, e o serviço reinicia sozinho de tempos em tempos. Sem a medição, a causa parece aleatória.

Quando a memória acaba: duas mortes diferentes

A segunda é a mais confusa, porque não deixa rastro no log da aplicação. E ela acontece quando o runtime não sabe que existe um limite.

O coletor precisa conhecer o limite

Um coletor de lixo decide quando coletar com base em quanto o heap cresceu. Se ele não sabe que o container tem 512 MB, pode deixar o lixo acumular além disso antes de coletar.

Reproduzimos com um programa Go que mantém 300 MB de dados em uso e cria 3 GB de objetos temporários, num container de 512 MB:

Os dados em uso cabiam com folga. O problema era o lixo: por padrão, o Go deixa o heap crescer até o dobro dos dados em uso antes de coletar, e o dobro de 300 MB passa de 512. Com o limite informado, o coletor passou a trabalhar mais cedo.

O Java mostra o problema oposto. No mesmo container, um programa que precisava de 250 MB falhou com OutOfMemoryError: por padrão, a JVM usa só 25% da memória do container para o heap, cerca de 123 MB. Com -XX:MaxRAMPercentage=75, o heap passou a 371 MB e o programa funcionou.

Por que isso importa quando a IA escreve o código

Assistentes escrevem caches, registros e coleções sem pensar em quanto eles crescem em produção:

• Um Map ou dicionário global usado como cache, sem limite de tamanho nem expiração.
• Um ouvinte de eventos registrado dentro de uma função chamada a cada pedido.
• Uma lista que acumula resultados "para estatísticas" e nunca é esvaziada.
• Goroutines disparadas sem forma de terminar quando o pedido é cancelado.
• O container configurado com um limite de memória e o runtime deixado no padrão.

O próximo nível compara as formas de configurar cada runtime e de evitar e encontrar vazamentos.