Kako Ruby upravlja memorijom i prikupljanjem smeća?

Question

Accepted Answer

Ruby upravlja memorijom **automatski** preko **prikupljača smeća (GC)** koji oslobađa objekte na koje se više ne referira. Moderni Ruby (MRI) koristi **generacijski, inkrementalni mark-and-sweep** prikupljač sa kompakcijom. Razumevanje toga pomaže sa performansama i dijagnostikom problema sa memorijom u dugoročno pokrenутим aplikacijama.

## Automatsko prikupljanje smeća

```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 vas oslobađa ručnog upravljanja memorijom. **Generacijski** pristup (često i jeftino prikupljanje mladih objekata, stari se retko prikupljaju) čini ga efikasnim, a inkrementalno prikupljanje smanjuje pauzе.

## Inspekcija i podešavanje 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 leakovi se i dalje dešavaju (uprkos 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.
```

## Zašto je to važno

Razumevanje Ruby-jezinog upravljanja memorijom i prikupljanjem smeća je dragoceno znanje, posebno za **dugoročno pokrenute Ruby aplikacije** (kao što su Rails web serveri, radni procesi na pozadini) gde ponašanje memorije bitno utiče na stabilnost i performanse.

Mada GC vas oslobađa ručnog upravljanja memorijom (što je ogromna korist za produktivnost), razumevanje *kako* funkcioniše pomaže sa podešavanjem performansi i dijagnostikom problema sa memorijom.

Znanje da moderni Ruby koristi **generacijski, inkrementalni, mark-and-sweep** prikupljač (često i jeftino prikupljanje mladih objekata, stari se retko prikupljaju, dok se rad raspoređuje da bi se smanjile pauzе) vam pomaže da razumete ponašanje GC i pritisak na njega, i da preterano dodeljívanje objekata povećava GC overhead (tako da smanjenje nepotrebnih dodela može poboljšati performanse).

Kritično je razumevanje da se **memory leakovi i dalje dešavaju** uprkos GC — jer GC oslobađa samo *nedostižne* objekte, pa se "leakovi" javljaju iz namernih **lingvističkih referenci** (globalne ili kolekcije na nivou klase koje samo rastu, kao neograničene memorijske keše; reference držane u dugoročnim objektima; veliki objekti čuvani živi kroz zatvaranja) — je važno za dijagnostiku i popravku rasta memorije koji muči dugoročno pokrenute Ruby procese (pravi, čest operativni problem).

Znanje o GC ponašanju, kako ga inspekovati (`GC.stat`, `ObjectSpace`), opcije za podešavanje, i posebno česte uzroke rasta memorije (zadržane reference) je dragoceno za rad performantnih, stabilnih Ruby aplikacija.

Pošto Ruby aplikacije (posebno Rails serveri) rade duže vreme a memory leakovi iz zadržanih referenci su česta problem iz realnog sveta, razumevanje Ruby GC — njegovog generacijskog mark-and-sweep modela, da ne može osloboditi dostižne objekte, i uzroci rasta memorije — je važno znanje za viši nivo u pogledu performansi i pouzdanosti, razlikuje developere koji mogu dijagnostifikovati i ispraviti probleme sa memorijom u produkciji Ruby, i relevantan je tema za uloge fokusirane na performanse.