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

Question

Accepted Answer

تدير Go **الذاكرة تلقائياً** بواسطة جامع قمامة، مما يحررك من التخصيص/التحرير اليدوي. جامع القمامة الخاص بها هو **جامع mark-and-sweep متزامن وقليل الكمون وغير جيلي** مصمم لتقليل أوقات الإيقاف — وهذا سبب رئيسي لملاءمة Go للخدمات الحساسة للكمون.

## المكدس مقابل الكومة وتحليل الهروب

```go
// the compiler decides where each value lives via ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // stays on the STACK — doesn't escape, freed when function returns (cheap)
    return x
}
func escapes() *int {
    x := 42        // ESCAPES to the HEAP — its pointer outlives the function (GC-managed)
    return &x
}
```

يقوم مترجم Go بإجراء **تحليل الهروب** في وقت الترجمة: القيم التي لا تتجاوز دالتها تبقى على **المكدس** الرخيص والمحرر تلقائياً؛ القيم التي تهرب مراجعها تذهب إلى **الكومة** (حيث يديرها جامع القمامة). تخصيص المكدس مجاني فعلياً، لذا فإن تقليل هروب الكومة يقلل عمل جامع القمامة.

## جامع القمامة: mark-and-sweep متزامن

```text
Go's GC characteristics:
  ✓ MARK-AND-SWEEP — marks reachable objects (from roots), sweeps the rest
  ✓ CONCURRENT — runs mostly alongside your program (not stop-the-world)
  ✓ LOW LATENCY — optimized for short pauses (typically sub-millisecond), not throughput
  ✓ NON-GENERATIONAL — unlike the JVM, treats all objects uniformly (simpler)
```

تعطي Go الأولوية عن قصد **لأوقات إيقاف قليلة** على الإنتاجية الخام — يقوم جامع القمامة بمعظم العمل بالتزامن مع برنامجك، مما يحافظ على فترات "التوقف عن العالم" قصيرة جداً. هذا يجعل Go قوية للخوادم الحساسة للكمون.

## ضبط جامع القمامة

```bash
GOGC=100   # default: trigger GC when heap grows 100% since the last collection
           # higher GOGC → less frequent GC (more memory, less CPU)
           # lower GOGC → more frequent GC (less memory, more CPU)
GOMEMLIMIT=2GiB   # a soft memory limit (Go 1.19+) — GC works harder near it
```

## تقليل ضغط جامع القمامة (تقنية الأداء)

```go
// 1. reuse objects with sync.Pool to reduce allocations
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)

// 2. preallocate slices with known capacity (avoid repeated growth/realloc)
data := make([]int, 0, 1000)

// 3. minimize heap escapes; avoid unnecessary pointers/allocations in hot loops
```

عدد أقل من التخصيصات = عمل جامع قمامة أقل. `sync.Pool` (إعادة استخدام الكائنات)، والتخصيص المسبق، وتقليل الهروب هي الطرق الرئيسية لتقليل ضغط جامع القمامة في المسارات الساخنة.

## تسريب الذاكرة يحدث حتى الآن

```text
GC frees only UNREACHABLE objects. Leaks come from lingering REFERENCES:
  ✗ goroutine leaks (a blocked goroutine keeps its referenced memory alive)
  ✗ growing global maps/slices, unclosed resources, forgotten subscriptions
```

## لماذا يهم

إدارة الذاكرة التلقائية في Go هي انتصار كبير من حيث الإنتاجية والأمان (بلا تحرير يدوي، بلا مؤشرات معلقة)، لكن فهم *كيف* تعمل مفيد جداً للتطبيقات الحساسة للأداء والكمون — وهي التطبيقات التي يتم اختيار Go لها غالباً.

الرؤى الرئيسية: **تحليل الهروب** يحدد تخصيص المكدس مقابل الكومة (المكدس مجاني؛ تقليل هروب الكومة يقلل عمل جامع القمامة)، و**جامع القمامة المتزامن قليل الكمون** في Go يعطي الأولوية للإيقافات القصيرة على الإنتاجية (مثالي للخوادم، بخلاف جامعات القمامة الموجهة للإنتاجية).

معرفة كيفية تقليل ضغط جامع القمامة (`sync.Pool`، التخصيص المسبق، تخصيصات أقل في الحلقات الساخنة)، وضبطه (`GOGC`، `GOMEMLIMIT`)، والاعتراف بأن **التسريب يحدث حتى الآن** من المراجع العالقة (خاصة تسريب الحلقات الروتينية) مهم لتشغيل خدمات Go عالية الأداء.

هذه معرفة عميقة وعملية تميز مطوري Go الكبار وهي موضوع مقابلة متقدم شائع للأدوار الحساسة للأداء.