Ce cauzeaza scurgerile de goroutine si cum le prevenii?

Question

Accepted Answer

O **scurgere de goroutine** este o goroutine care nu se termina niciodata — ramane blocata sau ruleaza la infinit, consumand memorie (si tinand obiectele referentiate vii) pe toata durata programului. Deoarece goroutine-urile sunt ieftine de inceput, este usor sa le scuturi, iar scurgerile se acumuleaza in tacere pana cand serviciul se degradeaza sau se epuizeaza memoria.

## Cauza 1: blocata pe un canal fara expeditor/receptor

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

O goroutine blocata pe o operatie de trimitere/receptie pe canal care nu se completeaza niciodata va astepta **la infinit** — nu se colecteaza niciodata ca gunoi deoarece este in continuare "in desfasurare".

## Cauza 2: fara anulare / semnal de finalizare

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

## Prevenire 1: foloseste context pentru anulare

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

Dandu-i fiecarei goroutine de lunga durata o modalitate de a fi anulata (`<-ctx.Done()`) este apararea primara — asigura ca goroutine-urile se termina cand munca lor nu mai este necesara.

## Prevenire 2: foloseste canale buferate sau asigura receptori

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

## Prevenire 3: inchide intotdeauna canalele / dreneaza-le corespunzator

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

## Detectarea scurgerilor

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

Supraveghearea `runtime.NumGoroutine()` (un numar care creste constant semnaleaza o scurgere), inspectarea image-urilor de goroutine prin `pprof` si folosirea `goleak` in teste sunt principalele instrumente de detectare.

## De ce conteaza

Scurgerile de goroutine sunt una dintre cele mai comune si periculoase probleme din serviciile Go in productie.

Deoarece goroutine-urile sunt atat de ieftine de lansat, dezvoltatorii le creeaza liber — dar o goroutine blocata la infinit (pe un canal fara echivalent, sau intr-o bucla infinita fara anulare) **nu se termina niciodata si nu elibereaza memoria** (inclusiv tot ceea ce referencieaza).

Intr-un server de lunga durata, aceste scurgeri se acumuleaza in tacere, consumand treptat memoria pana cand serviciul se degradeaza sau se prabuseste — si sunt greu de observat deoarece nu exista o eroare imediata.

Intelegerea cauzelor (operatii de canal blocate, anulare lipsa) si a preventiilor (**anularea bazata pe context** ca aparare primara, inchiderea corecta a canalelor, canale buferate, asigurarea receptorilor) este esentiala pentru scrierea unui Go concurrent de incredere.

Cunoasterea instrumentelor de detectare (`runtime.NumGoroutine`, pprof, goleak) este la fel de importanta.

Acesta este un subiect critic, testat frecvent, care separa dezvoltatorii care pot scrie Go concurrent de nivel productie de cei care scriu cod care se scurge sub sarcina sustinuta.