O que é Garbage Collection? Limpeza automática de memória
Garbage collection (GC) é o gerenciamento automático de memória: o runtime rastreia quais objetos ainda são alcançáveis e libera a memória daqueles que não são.
Em linguagens com garbage collection, você aloca memória criando objetos, mas raramente a libera de forma explícita. Um mecanismo em segundo plano, o garbage collector, encontra periodicamente objetos que nenhum caminho do programa consegue mais alcançar e recupera sua memória. Isso elimina toda uma categoria de bugs de memória manual ao custo de algum overhead de runtime e pausas ocasionais.
Como o GC decide o que liberar
Um collector parte das "roots" (variáveis globais, o stack, referências ativas) e rastreia todo objeto alcançável a partir delas. Qualquer coisa não alcançada é lixo e pode ser liberada. Esse modelo de alcançabilidade é a razão pela qual uma referência esquecida pode manter a memória viva por mais tempo do que você espera.
Estratégias comuns de coleta
- Mark-and-sweep: marca os objetos alcançáveis e depois varre o restante.
- Generacional: coleta com frequência objetos jovens de vida curta e raramente os antigos.
- Reference counting: libera um objeto quando sua contagem de referências chega a zero.
- Compacting: move objetos vivos para junto uns dos outros para reduzir a fragmentação.
O que o GC custa a você
Garbage collection troca controle manual por segurança. O preço é CPU gasta rastreando o heap e, em alguns collectors, pausas em que o programa para brevemente para o GC trabalhar. Collectors modernos minimizam essas pausas, mas elas nunca desaparecem por completo.
O GC não previne todos os leaks
Um garbage collector só libera memória inalcançável. Se o seu código mantém uma referência viva (em um cache, uma lista, um event listener), o objeto continua alcançável e nunca é coletado. Isso é um memory leak mesmo em uma linguagem com garbage collection.
Um exemplo rápido
Em um programa JavaScript ou Java, assim que nenhuma variável aponta para um objeto, o collector fica livre para recuperá-lo em seu próximo ciclo, sem nenhuma chamada free() da sua parte. Você simplesmente para de referenciar o objeto.
GC no CI
Test runs e builds podem pressionar o heap, e o overhead do GC cresce conforme a memória enche. Quando um processo excede a memória disponível, o runner pode fazer OOM-kill dele no meio de um teste. Runners maiores (Latchkey) dão mais espaço ao collector, e OOM kills transitórios podem ter retry automático para que um pico de memória não quebre um build que de outra forma estaria bom.
Principais conclusões
- Garbage collection libera automaticamente a memória de objetos que o programa não consegue mais alcançar.
- Elimina bugs de liberação manual, mas custa CPU e pode causar pausas ocasionais.
- O GC não impede leaks: uma referência ainda alcançável mantém a memória viva para sempre.