ما الذي يسبب تسرب goroutines وكيف تمنعه؟

Question

Accepted Answer

**تسرب goroutine** هو goroutine لا ينهي أبداً — يبقى محجوباً أو يعمل للأبد، مما يستهلك الذاكرة (ويحافظ على الكائنات المرجعية حية) طوال حياة البرنامج. وبما أن goroutines رخيصة في البداية، فمن السهل تسريبها، وتتراكم التسريبات بصمت حتى يتدهور الخدمة أو تنفد الذاكرة.

## السبب 1: محجوب على قناة بدون مرسل/متقبل

```go
// ❌ LEAK — this goroutine blocks forever waiting to send
func leak() {
    ch := make(chan int)   // unbuffered
    go func() {
        ch <- 42           // blocks forever — NOBODY ever receives
    }()                     // the goroutine is stuck, never exits
    // function returns without reading ch → the goroutine leaks
}
```

goroutine محجوب على إرسال/استقبال قناة لا ينتهي أبداً سينتظر **للأبد** — لا يتم جمع القمامة عليه أبداً لأنه تقنياً لا يزال "يعمل".

## السبب 2: لا إلغاء / إشارة تم

```go
// ❌ LEAK — a goroutine in an infinite loop with no way to stop
func worker(jobs <-chan int) {
    for {
        job := <-jobs      // blocks forever if jobs is never closed and stops sending
        process(job)
    }                       // no exit condition — leaks when no longer needed
}
```

## الوقاية 1: استخدم context للإلغاء

```go
// ✅ the goroutine can be told to stop
func worker(ctx context.Context, jobs <-chan int) {
    for {
        select {
        case job := <-jobs:
            process(job)
        case <-ctx.Done():       // cancellation signal → exit cleanly
            return                // the goroutine terminates, no leak
        }
    }
}
// caller: ctx, cancel := context.WithCancel(...); defer cancel()
```

إعطاء كل goroutine طويلة الأمد طريقة للإلغاء (`<-ctx.Done()`) هو الدفاع الأساسي — يضمن أن goroutines ينتهي عندما لا تكون هناك حاجة إلى عملهم.

## الوقاية 2: استخدم القنوات المؤقتة أو تأكد من وجود متقبلين

```go
// ✅ ensure a receiver exists, or use a buffered channel so the send doesn't block
ch := make(chan int, 1)   // buffered → the send completes even if no one receives yet
go func() { ch <- 42 }()   // doesn't block
```

## الوقاية 3: أغلق القنوات دائماً / صرفها بشكل صحيح

```go
// ✅ close channels so range loops terminate
go func() {
    defer close(results)    // signal completion → for-range over results ends
    for _, job := range jobs { results <- process(job) }
}()
```

## اكتشاف التسريبات

```go
runtime.NumGoroutine()         // monitor the goroutine count — steady growth = leak
import _ "net/http/pprof"      // pprof exposes goroutine stacks (/debug/pprof/goroutine)
// the goleak library asserts no leaked goroutines in tests
```

مراقبة `runtime.NumGoroutine()` (عدد متزايد باستمرار يشير إلى تسريب)، فحص حفرياً goroutine عبر `pprof`، واستخدام `goleak` في الاختبارات هي أدوات الكشف الرئيسية.

## لماذا يهم

تسريبات goroutine هي من أكثر المشاكل شيوعاً وإحداثاً للمشاكل في خدمات Go الإنتاجية.

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

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

فهم الأسباب (عمليات القناة المحجوبة، الإلغاء المفقود) والوقايات (**الإلغاء القائم على context** كدفاع أساسي، إغلاق القناة بشكل صحيح، القنوات المؤقتة، ضمان وجود متقبلين) ضروري لكتابة Go متزامن موثوق.

معرفة أدوات الكشف (`runtime.NumGoroutine`، pprof، goleak) لا تقل أهمية.

هذا موضوع حرج وكثير الاختبار يفصل بين المطورين الذين يمكنهم كتابة Go متزامن من درجة الإنتاج وأولئك الذين يكتبون كوداً يتسرب تحت الحمل المستمر.