Mi okozza a goroutine szivárgást és hogyan előzöd meg?

Question

Accepted Answer

A **goroutine szivárgás** egy olyan goroutine, amely soha nem fejeződik be — véglegesen blokkolódik vagy örökre fut, memóriát fogyaszt (és az által hivatkozott objektumokat életben tartja) a program teljes élettartama alatt. Mivel a goroutine-ok olcsók a létrehozásuk, könnyen szivárogtathatók, és a szivárgások csendesen halmozódnak, amíg a szolgáltatás nem romlik vagy ki nem fogy a memóriából.

## Ok 1: csatorna blokk, amelynek nincs küldője/fogadója

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

Egy csatorna küldésén/vételén blokkolódó goroutine, amely soha nem fejeződik be, **örökre** vár — soha nem kerül szemétgyűjtésre, mert technikailag még mindig "fut".

## Ok 2: nincs lemondás / végzett jel

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

## Megelőzés 1: context használata lemondáshoz

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

Minden hosszú élettartamú goroutine-nak megadni a lehetőséget, hogy lemondható legyen (`<-ctx.Done()`) — ez az elsődleges védelem, biztosítja, hogy a goroutine-ok befejeződjenek, amikor a munkájukra már nincs szükség.

## Megelőzés 2: pufferelt csatornák vagy biztosított fogadók

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

## Megelőzés 3: mindig zárd be a csatornákat / ürítsd ki őket megfelelően

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

## Szivárgások felderítése

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

A `runtime.NumGoroutine()` figyelése (egy folyamatosan emelkedő szám szivárgást jelez), goroutine dumfájlok vizsgálata a `pprof` segítségével, és a `goleak` használata tesztekben — ezek a fő felderítési eszközök.

## Miért számít ez

A goroutine szivárgások az egyik leggyakoribb és legcsínóbb probléma az éles Go szolgáltatásokban.

Mivel a goroutine-ok olyan olcsók a felindításukban, a fejlesztők szabadon létrehozzák őket — de egy goroutine, amely örökre blokkolódik (egy csatorna nélküli párján vagy végtelen ciklusban, amelynél nincs lemondás) **soha nem fejeződik be és soha nem ad fel memóriát** (beleértve mindent, amit hivatkozol).

Egy hosszú élettartamú szerveren ezek a szivárgások csendesen halmozódnak, fokozatosan fogyasztva a memóriát, amíg a szolgáltatás nem romlik vagy összeomlik — és nehéz felismerni őket, mert nincs azonnali hiba.

A причины megértése (blokkolódott csatorna műveletek, hiányzó lemondás) és a megelőzések (**context-alapú lemondás** mint elsődleges védelem, megfelelő csatorna bezárás, pufferelt csatornák, biztosított fogadók) elengedhetetlen az éles, konkurenciát támogató Go kód írásához.

A felderítési eszközök ismerete (`runtime.NumGoroutine`, pprof, goleak) ugyanilyen fontos.

Ez egy kritikus, gyakran tesztelt téma, amely szétválasztja azokat a fejlesztőket, akik képesek éles konkurens Go kódot írni, azokkal szemben, akik hosszú terhelés alatt szivárgó kódot írnak.