Ruby belleği nasıl yönetir ve çöp toplama nasıl çalışır?

Question

IT Interview Practice · Accepted Answer

Ruby belleği **otomatik olarak** artık referans edilmeyen nesneleri geri kazanan bir **çöp toplayıcı (GC)** aracılığıyla yönetir. Modern Ruby (MRI) **jenerasyonel, artan mark-and-sweep** toplayıcısını sıkıştırma ile kullanır. Bunu anlamak, performans ve uzun süren uygulamalarda bellek sorunlarını teşhis etmeye yardımcı olur.

## Otomatik çöp toplama

```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 sizi manuel bellek yönetiminden kurtarır. **Jenerasyonel** yaklaşım (genç nesneleri sık ve ucuz, eski nesneleri nadiren toplamak) bunu verimli hale getirir ve artan toplama duraklatmaları azaltır.

## GC'yi inceleme ve ayarlama

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

## Bellek sızıntıları yine de oluşur (GC'ye rağmen)

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

## Neden önemli

Ruby'nin bellek yönetimi ve çöp toplama hakkında bilgi sahibi olmak, özellikle bellek davranışının istikrar ve performans açısından önemli olduğu **uzun süren Ruby uygulamaları** (Rails web sunucuları, arka plan işçileri gibi) için değerli bilgidir.

GC sizi manuel bellek yönetiminden kurtarsa da (büyük bir verimlilik avantajı), *nasıl* çalıştığını anlamak performans ayarlanması ve bellek sorunlarını teşhis etmeye yardımcı olur.

Modern Ruby'nin **jenerasyonel, artan, mark-and-sweep** toplayıcısı kullandığını (genç nesneleri sık ve ucuz, eski nesneleri nadiren toplamak, işi yaymak için duraklatmaları azaltmak) bilmek GC davranışı ve baskısı hakkında düşünmenize yardımcı olur ve aşırı nesne tahsisi GC ek yükünü artırır (bu nedenle gereksiz tahsisleri azaltmak performansı iyileştirebilir).

Eleştirel olarak, GC'ye rağmen **bellek sızıntılarının hala oluşabileceğini** anlamak — çünkü GC yalnızca *erişilemeyen* nesneleri serbest bırakır, bu nedenle "sızıntılar" istenmeyen **kalıcı referanslardan** gelir (sadece büyüyen global veya sınıf düzeyindeki koleksiyonlar, sınırsız önbellekler gibi; uzun süren nesneler tarafından tutulan referanslar; kapatmalar tarafından yaşatılan büyük nesneler) — uzun süren Ruby işlemlerini taciz eden bellek artışını teşhis etmek ve düzeltmek için önemlidir (gerçek, yaygın bir operasyonel sorun).

GC'nin davranışını, bunu nasıl inceleyeceğini (`GC.stat`, `ObjectSpace`), ayarlama seçeneklerini ve özellikle bellek artışının yaygın nedenlerini (tutulan referanslar) bilmek, performans ve güvenilir Ruby uygulamaları işletmek için değerlidir.

Ruby uygulamaları (özellikle Rails sunucuları) uzun süre çalışır ve tutulan referanslardan kaynaklanan bellek sızıntıları sık karşılaşılan gerçek sorunlar olduğundan, Ruby'nin GC'sini — jenerasyonel mark-and-sweep modelini, erişilebilir nesneleri serbest bırakamayacağını ve bellek artışının nedenlerini — anlamak üretimde bellek sorunlarını teşhis edip düzeltebilen geliştiricileri ayıran, performans ve güvenilirlik için önemli üst düzey bilgidir ve performansa odaklanan roller için ilgili bir konudur.

Otomatik çöp toplama

GC'yi inceleme ve ayarlama

Bellek sızıntıları yine de oluşur (GC'ye rağmen)

Neden önemli

İlgili sorular