گوروٹین لیک کیا ہے اور آپ انہیں کیسے روکتے ہیں؟

Question

Accepted Answer

ایک **goroutine leak** ایک goroutine ہے جو کبھی ختم نہیں ہوتا — یہ مسلسل blocked رہتا ہے یا ہمیشہ چلتا رہتا ہے، میموری استعمال کرتے ہوئے (اور اپنے referenced اشیاء کو زندہ رکھتے ہوئے) پروگرام کی ساری مدت کے لیے۔ چونکہ goroutines شروع کرنے میں سستے ہیں، انہیں leak کرنا آسان ہے، اور leaks خاموشی سے جمع ہوتے ہیں جب تک سروس خراب نہ ہو یا میموری ختم نہ ہو۔

## وجہ 1: channel پر blocked جس کا کوئی sender/receiver نہیں ہے

```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 جو channel send/receive پر blocked ہے اور کبھی مکمل نہیں ہوتا وہ **ہمیشہ** انتظار کرتا رہے گا — یہ کبھی garbage collect نہیں ہوتا کیونکہ یہ تکنیکی طور پر ابھی بھی "چل رہا" ہے۔

## وجہ 2: کوئی cancellation / done signal نہیں ہے

```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: cancellation کے لیے 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()
```

ہر long-lived goroutine کو cancel کیے جانے کا طریقہ دینا (`<-ctx.Done()`) بنیادی دفاع ہے — یہ یقینی بناتا ہے کہ goroutines ختم ہو جائیں جب ان کا کام مزید ضروری نہ ہو۔

## روک تھام 2: buffered channels یا ensure receivers استعمال کریں

```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: ہمیشہ channels بند کریں / انہیں صحیح طریقے سے drain کریں

```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) }
}()
```

## Leaks کا پتا لگانا

```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()` کی نگرانی کرنا (مسلسل بڑھتی ہوئی تعداد leak کی نشاندہی کرتی ہے)، `pprof` کے ذریعے goroutine dumps کا معائنہ، اور tests میں `goleak` استعمال کرنا بنیادی detection کے اوزار ہیں۔

## یہ اہم کیوں ہے

Goroutine leaks production Go services میں سب سے عام اور خطرناک مسائل میں سے ایک ہیں۔

کیونکہ goroutines شروع کرنے میں بہت سستے ہیں، developers انہیں آزادانہ طریقے سے بناتے ہیں — لیکن ایک goroutine جو ہمیشہ کے لیے blocked ہے (channel پر جس کا کوئی counterpart نہیں ہے، یا infinite loop میں جس کا کوئی cancellation نہیں ہے) **کبھی ختم نہیں ہوتا اور اپنی میموری release نہیں کرتا** (بشمول وہ سب کچھ جس کا حوالہ دیتا ہے)۔

ایک long-running server میں، یہ leaks خاموشی سے جمع ہوتے ہیں، آہستہ آہستہ میموری استعمال کرتے ہیں جب تک سروس خراب نہ ہو یا crash نہ ہو — اور یہ پتا لگانے میں مشکل ہیں کیونکہ کوئی فوری error نہیں ہے۔

وجوہات (blocked channel operations، missing cancellation) اور روک تھام (**context-based cancellation** بنیادی دفاع کے طور پر، proper channel closing، buffered channels، ensuring receivers) کو سمجھنا قابل اعتماد concurrent Go لکھنے کے لیے ضروری ہے۔

Detection tools (`runtime.NumGoroutine`, pprof، goleak) کو جاننا یکساں اہم ہے۔

یہ ایک اہم، بار بار test ہونے والا موضوع ہے جو ان developers کو الگ کرتا ہے جو production-grade concurrent Go لکھ سکتے ہیں ان سے جو sustained load کے تحت leak کرنے والا code لکھتے ہیں۔