goroutine leaks किससे होते हैं और आप उन्हें कैसे रोकते हैं?

Question

Accepted Answer

एक **goroutine leak** एक ऐसी goroutine है जो कभी समाप्त नहीं होती — यह हमेशा के लिए blocked या चलती रहती है, program के जीवनकाल के लिए memory का उपभोग करती है (और अपने referenced objects को जीवित रखती है)। चूँकि goroutines शुरू करने में सस्ती हैं, उन्हें leak करना आसान है, और leaks चुपचाप तब तक जमा होते हैं जब तक service ख़राब न हो जाए या memory ख़त्म न हो जाए।

## कारण 1: बिना sender/receiver के channel पर blocked

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

हर लंबे समय तक चलने वाली goroutine को रोके जाने का एक तरीका देना (`<-ctx.Done()`) प्राथमिक बचाव है — यह सुनिश्चित करता है कि goroutines तब समाप्त हों जब उनका काम अब आवश्यक न हो।

## रोकथाम 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
```

## रोकथाम 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` का उपयोग मुख्य पता लगाने वाले उपकरण हैं।

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

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

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

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

कारणों (blocked channel operations, गायब cancellation) और रोकथामों (**context-based cancellation** प्राथमिक बचाव के रूप में, उचित channel closing, buffered channels, receivers सुनिश्चित करना) को समझना विश्वसनीय concurrent Go लिखने के लिए आवश्यक है।

पता लगाने वाले उपकरण (`runtime.NumGoroutine`, pprof, goleak) जानना भी उतना ही महत्वपूर्ण है।

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