How does Ruby manage memory and garbage collection?

Question

IT Interview Practice · Accepted Answer

Ruby manages memory **automatically** via a **garbage collector (GC)** that reclaims objects no longer referenced. Modern Ruby (MRI) uses a **generational, incremental mark-and-sweep** collector with compaction. Understanding it helps with performance and diagnosing memory issues in long-running applications.

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

The GC frees you from manual memory management. The **generational** approach (collecting young objects frequently and cheaply, old ones rarely) makes it efficient, and incremental collection reduces pauses.

## Inspecting and 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 still happen (despite 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.
```

## Why it matters

Understanding Ruby's memory management and garbage collection is valuable knowledge, particularly for **long-running Ruby applications** (like Rails web servers, background workers) where memory behavior matters for stability and performance.

While the GC frees you from manual memory management (a major productivity benefit), understanding *how* it works helps with performance tuning and diagnosing memory problems.

Knowing that modern Ruby uses a **generational, incremental, mark-and-sweep** collector (collecting young objects frequently and cheaply, old ones rarely, while spreading work to reduce pauses) helps you reason about GC behavior and pressure, and that excessive object allocation increases GC overhead (so reducing unnecessary allocations can improve performance).

Critically, understanding that **memory leaks still occur** despite the GC — because the GC only frees *unreachable* objects, so "leaks" come from unintended **lingering references** (global or class-level collections that only grow, like unbounded caches; references held in long-lived objects; large objects kept alive by closures) — is important for diagnosing and fixing the memory growth that plagues long-running Ruby processes (a real, common operational problem).

Knowing the GC's behavior, how to inspect it (`GC.stat`, `ObjectSpace`), tuning options, and especially the common causes of memory growth (retained references) is valuable for operating performant, stable Ruby applications.

Since Ruby applications (especially Rails servers) run for long periods and memory leaks from retained references are a frequent real-world issue, understanding Ruby's GC — its generational mark-and-sweep model, that it can't free reachable objects, and the causes of memory growth — is important senior-level knowledge for performance and reliability, distinguishing developers who can diagnose and fix memory issues in production Ruby, and a relevant topic for performance-focused roles.

Automatic garbage collection

Inspecting and tuning GC

Memory leaks still happen (despite GC)

Why it matters

Related questions