Como o Ruby gerencia memória e coleta de lixo?

Question

Accepted Answer

Ruby gerencia memória **automaticamente** por meio de um **coletor de lixo (GC)** que recupera objetos não mais referenciados. O Ruby moderno (MRI) usa um coletor **geracional, incremental e mark-and-sweep** com compactação. Entender isso ajuda com performance e diagnosticar problemas de memória em aplicações de longa duração.

## Coleta de lixo automática

```text
Ruby allocates objects on the heap; the GC reclaims those that are no longer REACHABLE
(referenced). You never free memory manually.

Modern MRI GC characteristics:
  ✓ Mark-and-sweep — marks reachable objects (from roots), sweeps unreachable ones
  ✓ Generational (since Ruby 2.1) — new objects collected often, old ones rarely
    (based on "most objects die young")
  ✓ Incremental — spreads GC work to reduce pause times
  ✓ Compacting (GC.compact, Ruby 2.7+) — reduces memory fragmentation
```

O GC o liberta do gerenciamento manual de memória. A abordagem **geracional** (coletando objetos jovens frequentemente e de forma barata, objetos antigos raramente) o torna eficiente, e a coleta incremental reduz pausas.

## Inspecionando e ajustando o GC

```ruby
GC.stat                    # detailed GC statistics (counts, heap info)
GC.start                   # manually trigger a collection (rarely needed)
GC.compact                 # compact the heap (reduce fragmentation)
ObjectSpace.count_objects  # counts of objects by type (debugging)
# environment variables (RUBY_GC_*) tune heap growth, etc.
```

## Vazamentos de memória ainda ocorrem (apesar do GC)

```ruby
# the GC frees only UNREACHABLE objects — "leaks" come from lingering references:
$global_cache = []
def process(item)
  $global_cache << item    # ❌ grows forever — never freed (still referenced)
end
```

```text
Common Ruby memory-growth causes:
  ✗ Global/class-level collections that only grow (caches, arrays)
  ✗ References held in long-lived objects (constants, class variables)
  ✗ Large objects kept alive by closures/blocks
→ The GC can't free reachable objects, so "leaks" = unintended retained references.
```

## Por que isso importa

Entender o gerenciamento de memória e coleta de lixo do Ruby é conhecimento valioso, particularmente para **aplicações Ruby de longa duração** (como servidores web Rails, workers em background) onde o comportamento da memória importa para estabilidade e performance.

Ao mesmo tempo que o GC o liberta do gerenciamento manual de memória (um grande benefício de produtividade), entender *como* funciona ajuda com ajuste de performance e diagnóstico de problemas de memória.

Saber que o Ruby moderno usa um coletor **geracional, incremental e mark-and-sweep** (coletando objetos jovens frequentemente e de forma barata, objetos antigos raramente, enquanto distribui o trabalho para reduzir pausas) ajuda você a raciocinar sobre comportamento e pressão do GC, e que alocação excessiva de objetos aumenta overhead do GC (então reduzir alocações desnecessárias pode melhorar performance).
\_Criticamente, entender que **vazamentos de memória ainda ocorrem** apesar do GC — porque o GC apenas liberta objetos *inacessíveis*, então "vazamentos" vêm de **referências intencionais** (coleções globais ou em nível de classe que apenas crescem, como caches ilimitados; referências mantidas em objetos de longa duração; objetos grandes mantidos vivos por closures) — é importante para diagnosticar e corrigir o crescimento de memória que assola processos Ruby de longa duração (um problema operacional real e comum).

Saber o comportamento do GC, como inspecioná-lo (`GC.stat`, `ObjectSpace`), opções de ajuste, e especialmente as causas comuns de crescimento de memória (referências retidas) é valioso para operar aplicações Ruby com boa performance e estáveis.

Como aplicações Ruby (especialmente servidores Rails) rodam por longos períodos e vazamentos de memória de referências retidas são um problema frequente no mundo real, entender o GC do Ruby — seu modelo geracional mark-and-sweep, que ele não pode liberar objetos acessíveis, e as causas de crescimento de memória — é conhecimento importante de nível sênior para performance e confiabilidade, diferenciando desenvolvedores que podem diagnosticar e corrigir problemas de memória em Ruby em produção, e um tópico relevante para funções focadas em performance.