Što uzrokuje curenja goroutine-ova i kako ih sprječavate?

Question

Accepted Answer

A **goroutine leak** je goroutine koji nikad nije završio — ostaje blokiran ili trči zauvijek, konzumirajući memoriju (i keeping its referenced objects alive) tijekom životnog vijeka programa. Pošto su goroutine-ovi jeftini za pokretanje, lako je curiti goroutine-ove, i curenja se akumuliraju tiho dok se usluga ne degradira ili ne ponestane memorije.

## Uzrok 1: blokiran na kanalu bez pošiljaoca/primatelja

```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 blokiran na kanalu send/receive koji se nikad ne dovršiti čekati **zauvijek** — nikad se ne garbage collects jer je tehnički još uvijek "running".

## Uzrok 2: nema otkazivanja / done signala

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

## Prevencija 1: koristi context za otkazivanje

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

Davanje svakom dugoročnom goroutine-u načina da se otkaže (`<-ctx.Done()`) je primarni obrambeni mehanizam — osigurava da goroutine-ovi završe kada njihov rad više nije potreban.

## Prevencija 2: koristi buffered kanale ili osiguraj primatelje

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

## Prevencija 3: uvijek zatvori kanale / isprazni ih pravilno

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

## Detektiranje curenja

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

Nadzor `runtime.NumGoroutine()` (stalno rastući broj signalizira curenje), inspektiranje goroutine dump-eva putem `pprof`-a, i korištenje `goleak`-a u testima su glavni alati za detekciju.

## Zašto je to važno

Curenja goroutine-ova su jedan od najčešćih i najopasnijih problema u proizvodnim Go uslugama.

Jer su goroutine-ovi tako jeftini za pokretanje, programeri ih kreiraju slobodno — ali goroutine blokiran zauvijek (na kanalu bez protivnika, ili u beskonačnoj petlji bez otkazivanja) **nikad se ne završi i nikad ne oslobodi svoju memoriju** (uključujući sve na što se odnosi).

U dugoročnom serveru, ta curenja se akumuliraju tiho, postupno konzumirajući memoriju dok se usluga ne degradira ili se sruši — i teško se otkrivaju jer nema odmah greške.

Razumijevanje uzroka (blokirane operacije kanala, nedostaje otkazivanje) i prevencije (**context-based otkazivanje** kao primarni obrambeni mehanizam, pravilno zatvaranje kanala, buffered kanali, osiguranje primatelja) je bitno za pisanje pouzdanog konkurentnog Go-a.

Znanje alata za detekciju (`runtime.NumGoroutine`, pprof, goleak) je jednako važno.

Ovo je kritična, često testirana tema koja odvaja programere koji mogu pisati proizvodni konkurentni Go od onih koji pišu kod koji curi pod održavanom opterećenjem.