Bagaimana Ruby mengelola memori dan garbage collection?

Question

Accepted Answer

Ruby mengelola memori **secara otomatis** melalui **garbage collector (GC)** yang membebaskan objek yang tidak lagi dirujuk. Ruby modern (MRI) menggunakan kolektor **generational, incremental mark-and-sweep** dengan compaction. Memahaminya membantu dengan performa dan diagnosis masalah memori dalam aplikasi yang berjalan lama.

## Garbage collection otomatis

```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 membebaskan Anda dari manajemen memori manual. Pendekatan **generational** (mengumpulkan objek muda sering dan murah, objek lama jarang) membuatnya efisien, dan pengumpulan incremental mengurangi pause.

## Inspeksi dan tuning 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 leaks masih terjadi (meskipun ada 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.
```

## Mengapa ini penting

Memahami manajemen memori dan garbage collection Ruby adalah pengetahuan berharga, khususnya untuk **aplikasi Ruby yang berjalan lama** (seperti web server Rails, background workers) di mana perilaku memori penting untuk stabilitas dan performa.

Meskipun GC membebaskan Anda dari manajemen memori manual (manfaat produktivitas besar), memahami *bagaimana* cara kerjanya membantu dengan tuning performa dan diagnosis masalah memori.

Mengetahui bahwa Ruby modern menggunakan kolektor **generational, incremental, mark-and-sweep** (mengumpulkan objek muda sering dan murah, objek lama jarang, sambil menyebarkan pekerjaan untuk mengurangi pause) membantu Anda bernalar tentang perilaku dan tekanan GC, dan alokasi objek berlebihan meningkatkan overhead GC (jadi mengurangi alokasi yang tidak perlu dapat meningkatkan performa).

Secara kritis, memahami bahwa **memory leaks masih terjadi** meskipun ada GC — karena GC hanya membebaskan objek *yang tidak dapat dijangkau*, jadi "leaks" berasal dari **referensi yang tertinggal** yang tidak disengaja (koleksi global atau class-level yang terus bertumbuh, seperti cache tak terbatas; referensi yang dipegang oleh objek yang berumur panjang; objek besar yang tetap hidup oleh closure) — penting untuk diagnosis dan perbaikan pertumbuhan memori yang mengganggu proses Ruby yang berjalan lama (masalah operasional nyata dan umum).

Mengetahui perilaku GC, cara menginspeksinya (`GC.stat`, `ObjectSpace`), opsi tuning, dan khususnya penyebab umum pertumbuhan memori (referensi yang dipertahankan) berharga untuk mengoperasikan aplikasi Ruby yang performan dan stabil.

Karena aplikasi Ruby (terutama server Rails) berjalan untuk waktu lama dan memory leaks dari referensi yang dipertahankan adalah masalah real-world yang sering, memahami GC Ruby — model generational mark-and-sweep-nya, bahwa itu tidak dapat membebaskan objek yang dapat dijangkau, dan penyebab pertumbuhan memori — adalah pengetahuan level senior yang penting untuk performa dan keandalan, membedakan developer yang dapat mendiagnosis dan memperbaiki masalah memori di Ruby produksi, dan topik yang relevan untuk peran yang berfokus pada performa.