गोरूटीन लीक्स का कारण बनते हैं और आप उन्हें कैसे रोकते हैं?

Question

Accepted Answer

एक **goroutine leak** एक goroutine है जो कभी समाप्त नहीं होता — यह ब्लॉक रहता है या हमेशा के लिए चल रहा होता है, मेमोरी का उपभोग करता है (और अपने संदर्भित ऑब्जेक्ट्स को जीवित रखता है) प्रोग्राम के जीवनकाल के लिए। चूंकि goroutines शुरू करने के लिए सस्ते हैं, इसलिए उन्हें लीक करना आसान है, और लीक्स चुप चाप जमा होते हैं जब तक कि सेवा खराब न हो जाए या मेमोरी समाप्त न हो जाए।

## कारण 1: कोई भेजने वाला/प्राप्तकर्ता के साथ channel पर ब्लॉक किया गया

```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 पर ब्लॉक किया गया है जो कभी पूरा नहीं होता **forever** के लिए इंतज़ार करेगा — यह कभी 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
}
```

## Prevention 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 को cancelled होने का तरीका देना (`<-ctx.Done()`) प्राथमिक defense है — यह सुनिश्चित करता है कि जब उनका काम अब आवश्यक न रह जाए तो goroutines समाप्त हो जाएं।

## Prevention 2: buffered channels का उपयोग करें या 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
```

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

## लीक्स का पता लगाना

```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()` की निगरानी करना (एक लगातार बढ़ती गिनती एक लीक का संकेत देती है), `pprof` के माध्यम से goroutine dumps का निरीक्षण करना, और परीक्षणों में `goleak` का उपयोग करना मुख्य detection tools हैं।

## यह महत्वपूर्ण क्यों है

Goroutine leaks production Go services में सबसे आम और सबसे घातक समस्याओं में से एक हैं।

क्योंकि goroutines लॉन्च करने के लिए बहुत सस्ते हैं, developers उन्हें स्वतंत्र रूप से बनाते हैं — लेकिन एक goroutine जो हमेशा के लिए ब्लॉक किया गया है (कोई counterpart के बिना एक channel पर, या cancellation के बिना एक अनंत loop में) **कभी समाप्त नहीं होता और कभी अपनी memory release नहीं करता** (इसमें वह सब कुछ भी शामिल है जो यह संदर्भित करता है)।

एक long-running server में, ये leaks चुप चाप जमा होते हैं, धीरे-धीरे memory का उपभोग करते हैं जब तक कि सेवा खराब न हो जाए या crash न हो जाए — और उन्हें spot करना मुश्किल है क्योंकि कोई तत्काल error नहीं है।

कारणों को समझना (blocked channel operations, missing cancellation) और preventions (**context-based cancellation** primary defense के रूप में, proper channel closing, buffered channels, receivers सुनिश्चित करना) production-grade concurrent Go लिखने के लिए आवश्यक है।

Detection tools को जानना (`runtime.NumGoroutine`, pprof, goleak) समान रूप से महत्वपूर्ण है।

यह एक महत्वपूर्ण, अक्सर-परीक्षित विषय है जो उन developers को अलग करता है जो production-grade concurrent Go लिख सकते हैं उन लोगों से जो code लिखते हैं जो sustained load के तहत लीक होता है।