كيف تدير Ruby الذاكرة وجمع القمامة؟

Question

Accepted Answer

تدير Ruby الذاكرة **تلقائياً** عبر **مجمِّع القمامة (GC)** الذي يعيد استخدام الكائنات التي لا تحتفظ بها أي مراجع. يستخدم Ruby الحديث (MRI) **مجمِّع mark-and-sweep تدريجياً وموزعاً على أجيال** مع إمكانية الضغط. فهم هذه الآلية يساعدك على تحسين الأداء وتشخيص مشاكل الذاكرة في التطبيقات طويلة الأمد.

## جمع القمامة التلقائي

```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 من إدارة الذاكرة اليدوية. يجعل النهج **الموزع على أجيال** (جمع الكائنات الفتية بتكرار وبكفاءة، والقديمة نادراً) فعّالاً جداً، والجمع التدريجي يقلل من فترات التوقف.

## فحص وضبط 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.
```

## تسريب الذاكرة يحدث برغم 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.
```

## لماذا هذا مهم

فهم إدارة الذاكرة وجمع القمامة في Ruby معرفة قيّمة جداً، خاصة بالنسبة **للتطبيقات طويلة الأمد في Ruby** (مثل خوادم Rails، عمليات المعالجة في الخلفية) حيث يؤثر السلوك الذاكري على الاستقرار والأداء.

بينما يُحررك GC من إدارة الذاكرة اليدوية (فائدة إنتاجية كبيرة)، فإن فهم *كيفية* عمله يساعدك على ضبط الأداء وتشخيص مشاكل الذاكرة.

معرفة أن Ruby الحديث يستخدم **مجمِّع mark-and-sweep موزع على أجيال وتدريجياً** (جمع الكائنات الفتية بتكرار وبكفاءة، والقديمة نادراً، مع توزيع العمل لتقليل فترات التوقف) يساعدك على فهم سلوك ضغط GC والحمل عليه، وأن التخصيص الزائد للكائنات يزيد من نفقات GC (لذا فإن تقليل التخصيصات غير الضرورية يحسن الأداء).

من الضروري فهم أن **تسريب الذاكرة يحدث برغم GC** — لأن GC يحرر فقط الكائنات *غير القابلة للوصول*، لذا فإن "التسريب" ينجم عن **مراجع باقية غير مقصودة** (مجموعات عامة أو على مستوى الفئة التي تنمو بلا حد، مثل caches غير محدودة؛ مراجع محتفظ بها في كائنات طويلة الأمد؛ كائنات كبيرة يتم الاحتفاظ بها على قيد الحياة بواسطة closures) — وهذا أمر مهم لتشخيص وإصلاح نمو الذاكرة الذي يؤرق عمليات Ruby طويلة الأمد (مشكلة عملية حقيقية وشائعة).

معرفة سلوك GC وكيفية فحصه (`GC.stat`, `ObjectSpace`)، خيارات الضبط، وخاصة الأسباب الشائعة لنمو الذاكرة (الاحتفاظ بالمراجع) قيّمة جداً لتشغيل تطبيقات Ruby فعّالة واستقرار.

بما أن تطبيقات Ruby (خاصة خوادم Rails) تعمل لفترات طويلة وتسريب الذاكرة من المراجع المحتفظ بها مشكلة متكررة وشائعة جداً في الإنتاج، فإن فهم GC في Ruby — نموذجه الموزع على أجيال مع mark-and-sweep، أنه لا يمكنه تحرير الكائنات القابلة للوصول، وأسباب نمو الذاكرة — معرفة مهمة على مستوى كبار المطورين للأداء والموثوقية، وتميز المطورين الذين يستطيعون تشخيص وإصلاح مشاكل الذاكرة في Ruby الإنتاجي، وموضوع ذو صلة للأدوار التي تركز على الأداء.