goroutine leaks-ஐ எது ஏற்படுத்துகிறது மற்றும் அவற்றை எவ்வாறு தடுப்பீர்கள்?

Question

Accepted Answer

ஒரு **goroutine leak** என்பது ஒருபோதும் முடிவடையாத ஒரு goroutine — அது நிரந்தரமாக blocked ஆகவோ அல்லது running ஆகவோ இருக்கிறது, program-இன் வாழ்நாள் முழுவதும் memory-ஐ உட்கொள்கிறது (மற்றும் அது குறிப்பிடும் 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
}
```

ஒருபோதும் முடியாத channel send/receive-இல் blocked ஆன ஒரு goroutine **நிரந்தரமாக** காத்திருக்கும் — அது தொழில்நுட்ப ரீதியாக இன்னும் "running" ஆக இருப்பதால் ஒருபோதும் 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-ஐ பயன்படுத்துதல் அல்லது 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-ஐ close செய்தல் / சரியாக 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 அவற்றை சுதந்திரமாக உருவாக்குகிறார்கள் — ஆனால் நிரந்தரமாக blocked ஆன ஒரு goroutine (counterpart இல்லாத channel-இல், அல்லது cancellation இல்லாத infinite loop-இல்) **ஒருபோதும் முடிவடைவதில்லை மற்றும் அதன் memory-ஐ (அது குறிப்பிடும் அனைத்தையும் உள்ளடக்கி) ஒருபோதும் விடுவிப்பதில்லை**.

ஒரு long-running server-இல், இந்த leaks அமைதியாகக் குவிந்து, service சிதைவடையும் அல்லது crash ஆகும் வரை memory-ஐ படிப்படியாக உட்கொள்கின்றன — மேலும் உடனடி error இல்லாததால் அவற்றைக் கண்டறிவது கடினம்.

காரணங்களை (blocked channel operations, missing cancellation) மற்றும் தடுப்புகளை (**context அடிப்படையிலான cancellation** முதன்மை பாதுகாப்பாக, சரியான channel closing, buffered channels, receivers-ஐ உறுதிசெய்தல்) புரிந்துகொள்வது, நம்பகமான concurrent Go எழுதுவதற்கு அவசியமாகும்.

கண்டறிதல் கருவிகளை (`runtime.NumGoroutine`, pprof, goleak) அறிவதும் சமமாக முக்கியம்.

இது ஒரு முக்கியமான, அடிக்கடி சோதிக்கப்படும் தலைப்பாகும்; production-தர concurrent Go எழுதக்கூடிய developers-ஐ, நீடித்த load-இல் leak செய்யும் code எழுதுபவர்களிடமிருந்து இது வேறுபடுத்துகிறது.