Jak Ruby spravuje paměť a garbage collection?

Question

Accepted Answer

Ruby spravuje paměť **automaticky** prostřednictvím **garbage collectoru (GC)**, který uvolňuje objekty, na které se již nikdo neodkazuje. Moderní Ruby (MRI) používá **generační, inkrementální mark-and-sweep** collector s kompakcí. Pochopení jeho fungování pomáhá s výkonem a diagnostikou problémů s pamětí v dlouhotrvajících aplikacích.

## Automatický garbage collection

```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
```

GC vás osvobozuje od ruční správy paměti. **Generační** přístup (běžné a levné sbírání mladých objektů, vzácné sbírání starých) jej činí efektivním, a inkrementální sběr snižuje pauzy.

## Inspekce a optimalizace 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.
```

## Memory leaky se mohou stát (navzdory 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.
```

## Proč je to důležité

Pochopení správy paměti a garbage collection v Ruby je cenné vědomí, zvláště pro **dlouhotrvající Ruby aplikace** (jako Rails webové servery, background workery), kde chování paměti záleží na stabilitě a výkonu.

Ačkoli GC vás osvobozuje od ruční správy paměti (hlavní přínos pro produktivitu), pochopení *jak* funguje vám pomáhá s optimalizací výkonu a diagnostikou problémů s pamětí.

Vědomí, že moderní Ruby používá **generační, inkrementální, mark-and-sweep** collector (sbírá mladé objekty často a levně, staré jen vzácně, zatímco rozprostírá práci aby se snížily pauzy) vám pomáhá pochopit chování GC a tlak na něj, a že nadměrná alokace objektů zvyšuje GC overhead (takže snížení zbytečných alokací může zlepšit výkon).

Kriticky důležité je pochopení, že **memory leaky se stále mohou vyskytnout** navzdory GC — protože GC uvolňuje jen *nedostupné* objekty, takže "leaky" pocházejí z nežádoucích **lingujících odkazů** (globální nebo class-level sbírky, které pouze rostou, jako neomezené cache; odkazy držené v dlouhotrvajících objektech; velké objekty udržované naživu closures) — je důležité pro diagnostikou a opravu paměti růstu, který trápí dlouhotrvající Ruby procesy (reálný, běžný operační problém).

Vědomí chování GC, jak jej inspekovat (`GC.stat`, `ObjectSpace`), možnosti optimalizace a zvláště běžné příčiny paměti růstu (zadržené odkazy) je cenné pro provoz výkonných, stabilních Ruby aplikací.

Protože Ruby aplikace (zvláště Rails servery) běží dlouhé doby a memory leaky z retinovaných odkazů jsou čestý reálný problém, pochopení Ruby GC — jeho generačního mark-and-sweep modelu, že nemůže uvolnit dosažitelné objekty, a příčiny paměti růstu — je důležité senior-level vědomí pro výkon a spolehlivost, rozlišující vývojáře, kteří mohou diagnostikovat a opravit problémy s pamětí v produkčním Ruby, a relevantní téma pro role zaměřené na výkon.