Ruby quản lý bộ nhớ và garbage collection thế nào?

Question

Accepted Answer

Ruby quản lý bộ nhớ **tự động** thông qua một **garbage collector (GC)** thu hồi các object không còn được tham chiếu. Ruby hiện đại (MRI) dùng một collector **mark-and-sweep theo thế hệ (generational), incremental** với compaction. Hiểu nó giúp ích cho hiệu năng và chẩn đoán các vấn đề bộ nhớ trong các ứng dụng chạy lâu.

## Garbage collection tự động

```text
Ruby cấp phát object trên heap; GC thu hồi những object không còn TIẾP CẬN ĐƯỢC
(được tham chiếu). Bạn không bao giờ giải phóng bộ nhớ thủ công.

Đặc điểm GC của MRI hiện đại:
  ✓ Mark-and-sweep — đánh dấu object tiếp cận được (từ root), quét bỏ object không tiếp cận được
  ✓ Theo thế hệ (từ Ruby 2.1) — object mới được thu thường xuyên, object cũ hiếm khi
    (dựa trên "hầu hết object chết sớm")
  ✓ Incremental — trải đều công việc GC để giảm thời gian dừng (pause)
  ✓ Compacting (GC.compact, Ruby 2.7+) — giảm phân mảnh bộ nhớ
```

GC giải phóng bạn khỏi việc quản lý bộ nhớ thủ công. Cách tiếp cận **theo thế hệ** (thu các object trẻ thường xuyên và rẻ, object cũ hiếm khi) làm nó hiệu quả, và thu thập incremental giảm thời gian dừng.

## Kiểm tra và tinh chỉnh GC

```ruby
GC.stat                    # thống kê GC chi tiết (số đếm, thông tin heap)
GC.start                   # kích hoạt thu thập thủ công (hiếm khi cần)
GC.compact                 # nén heap (giảm phân mảnh)
ObjectSpace.count_objects  # số đếm object theo kiểu (debug)
# biến môi trường (RUBY_GC_*) tinh chỉnh tăng trưởng heap, v.v.
```

## Rò rỉ bộ nhớ vẫn xảy ra (dù có GC)

```ruby
# GC chỉ giải phóng object KHÔNG TIẾP CẬN ĐƯỢC — "rò rỉ" đến từ các tham chiếu còn vương lại:
$global_cache = []
def process(item)
  $global_cache << item    # ❌ tăng trưởng mãi mãi — không bao giờ được giải phóng (vẫn được tham chiếu)
end
```

```text
Các nguyên nhân tăng trưởng bộ nhớ thường gặp trong Ruby:
  ✗ Tập hợp cấp global/class chỉ tăng lên (cache, array)
  ✗ Tham chiếu được giữ trong các object sống lâu (hằng số, biến class)
  ✗ Object lớn được giữ sống bởi closure/block
→ GC không thể giải phóng object tiếp cận được, nên "rò rỉ" = tham chiếu được giữ lại ngoài ý muốn.
```

## Tại sao điều này quan trọng

Hiểu việc quản lý bộ nhớ và garbage collection của Ruby là kiến thức có giá trị, đặc biệt cho các **ứng dụng Ruby chạy lâu** (như web server Rails, background worker) nơi hành vi bộ nhớ quan trọng cho sự ổn định và hiệu năng.

Dù GC giải phóng bạn khỏi việc quản lý bộ nhớ thủ công (một lợi ích năng suất lớn), hiểu *cách* nó hoạt động giúp ích cho việc tinh chỉnh hiệu năng và chẩn đoán các vấn đề bộ nhớ.

Biết rằng Ruby hiện đại dùng một collector **mark-and-sweep, theo thế hệ, incremental** (thu các object trẻ thường xuyên và rẻ, object cũ hiếm khi, đồng thời trải đều công việc để giảm thời gian dừng) giúp bạn suy luận về hành vi và áp lực GC, và rằng việc cấp phát object quá mức làm tăng overhead của GC (nên giảm các cấp phát không cần thiết có thể cải thiện hiệu năng).

Quan trọng nhất, hiểu rằng **rò rỉ bộ nhớ vẫn xảy ra** dù có GC — vì GC chỉ giải phóng object *không tiếp cận được*, nên "rò rỉ" đến từ các **tham chiếu còn vương lại** ngoài ý muốn (tập hợp cấp global hoặc class chỉ tăng lên, như cache không giới hạn; tham chiếu được giữ trong các object sống lâu; object lớn được giữ sống bởi closure) — là quan trọng để chẩn đoán và sửa sự tăng trưởng bộ nhớ làm phiền các tiến trình Ruby chạy lâu (một vấn đề vận hành thực sự, thường gặp).

Biết hành vi của GC, cách kiểm tra nó (`GC.stat`, `ObjectSpace`), các tùy chọn tinh chỉnh, và đặc biệt là các nguyên nhân thường gặp của tăng trưởng bộ nhớ (tham chiếu được giữ lại) là có giá trị để vận hành các ứng dụng Ruby hiệu năng cao, ổn định.

Vì các ứng dụng Ruby (đặc biệt là server Rails) chạy trong thời gian dài và rò rỉ bộ nhớ từ tham chiếu được giữ lại là vấn đề thực tế thường gặp, hiểu GC của Ruby — mô hình mark-and-sweep theo thế hệ của nó, rằng nó không thể giải phóng object tiếp cận được, và các nguyên nhân tăng trưởng bộ nhớ — là kiến thức cấp senior quan trọng cho hiệu năng và độ tin cậy, phân biệt các developer có thể chẩn đoán và sửa các vấn đề bộ nhớ trong Ruby production, và là chủ đề liên quan cho các vai trò tập trung vào hiệu năng.