Mikä aiheuttaa goroutine-vuotoja ja kuinka ne estetään?

Question

Accepted Answer

**Goroutine-vuoto** on goroutine, joka ei koskaan pääty – se jää jumiin tai kulkee ikuisesti, kuluttaen muistia (ja pitäen viitattuja objekteja elossa) ohjelman koko elinkaaren ajan. Koska goroutineja on halpaa käynnistää, on helppo vuotaa niitä, ja vuodot kertyvät hiljaisesti kunnes palvelu huonontuu tai muisti loppuu.

## Syy 1: kanavassa jumiutunut ilman lähettäjää/vastaanottajaa

```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, joka on jumiutunut kanavan lähettämiseen/vastaanottamiseen, joka ei koskaan valmistuu, odottaa **ikuisesti** – sitä ei koskaan roskienkeräämät poisteta, koska se on teknisesti vielä "käynnissä".

## Syy 2: ei peruutusta / done-signaalia

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

## Ehkäisy 1: käytä kontekstia peruuttamiseen

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

Jokaisen pitkäikäisen goroutinen antaminen peruutusmahdollisuudella (`<-ctx.Done()`) on ensisijainen puolustus – se varmistaa, että goroutineet päättyvät, kun niiden työ ei ole enää tarpeen.

## Ehkäisy 2: käytä puskuroituja kanavia tai varmista vastaanottajat

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

## Ehkäisy 3: aina sulje kanavat / tyhjennä ne oikein

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

## Vuotojen havaitseminen

```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()`n seuranta (jatkuvasti nouseva lukumäärä ilmaisee vuotoa), goroutine-vedosten tarkastelu `pprof`in kautta ja `goleak`in käyttö testeissä ovat pääasialliset havaitsemisen työkalut.

## Miksi se on tärkeää

Goroutine-vuodot ovat yksi yleisimmistä ja petollisuimmista ongelmista tuotannon Go-palveluissa.

Koska goroutineja on niin halpaa käynnistää, kehittäjät luovat niitä vapaasti – mutta goroutine, joka on jumiutunut ikuisesti (kanavalla ilman vastinetta tai äärettömässä silmukassa ilman peruutusta), **ei koskaan pääty eikä vapauta muistiaan** (mukaan lukien kaikki, mihin se viittaa).

Pitkäikäisessä palvelimessa nämä vuodot kertyvät hiljaisesti, kuluttaen muistia vähitellen, kunnes palvelu huonontuu tai kaatuu – ja ne on vaikea havaita, koska välitöntä virhettä ei ole.

Syiden (jumiutuneet kanavatoiminnot, puuttuva peruutus) ja ehkäisykeinojen (**kontekstiin perustuva peruutus** pääpuolustuksena, asianmukainen kanavan sulkeminen, puskuroidut kanavat, vastaanottajien varmistaminen) ymmärtäminen on välttämätöntä luotettavan rinnakkaisen Go:n kirjoittamiselle.

Havaitsemistyökalujen tuntemus (`runtime.NumGoroutine`, pprof, goleak) on yhtä tärkeää.

Tämä on kriittinen, usein testattu aihe, joka erottaa kehittäjät, jotka voivat kirjoittaa tuotantolaatuista rinnakkaista Go:ta, niistä, jotka kirjoittavat koodia, joka vuotaa kestävällä kuormalla.