Goroutine sızıntılarına neden olan şeyler nelerdir ve bunları nasıl önlersiniz?

Question

Accepted Answer

Bir **goroutine sızıntısı**, asla sonlanmayan bir goroutine'dir — engellenmiş veya sonsuza kadar çalışan, belleği tüketen (ve referans aldığı nesneleri canlı tutan) bir goroutine'dir. Goroutine'ler başlatması ucuz olduğu için onları sızmak kolaydır ve sızıntılar hizmet performansı düşene veya bellek bitene kadar sessizce birikir.

## Neden 1: kanala alıcısı/göndericisi olmadan engellendi

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

Asla tamamlanmayan bir kanal gönderme/alma işleminde engellenen bir goroutine **sonsuza kadar** beklenir — teknik olarak hala "çalışıyor" olduğundan çöp olarak toplanmaz.

## Neden 2: iptal etme / done sinyali yok

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

## Önleme 1: iptal etme için context kullanın

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

Her uzun ömürlü goroutine'e iptal edilebilme yolu vermek (`<-ctx.Done()`) birincil savunmadır — goroutine'lerin çalışması artık gerekli olmadığında sonlanmasını sağlar.

## Önleme 2: arabelleğe alınmış kanallar kullanın veya alıcılar sağlayın

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

## Önleme 3: her zaman kanalları kapatın / onları düzgün şekilde drainleyin

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

## Sızıntı tespiti

```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()` izlemesi (sürekli artan sayı sızıntıyı işaret eder), `pprof` aracılığıyla goroutine dökümleri incelemesi ve testlerde `goleak` kullanımı ana tespit araçlarıdır.

## Neden önemli

Goroutine sızıntıları, üretim ortamındaki Go hizmetlerinde en yaygın ve en sinsi sorunlardan biridir.

Goroutine'ler başlatması çok ucuz olduğu için, geliştiriciler onları özgürce oluştururlar — ancak sonsuza kadar (hiçbir karşılığı olmayan bir kanalda bloke edilmiş veya iptal etme olmayan sonsuz bir döngüde) engellenen bir goroutine **asla sonlanmaz ve belleğini serbest bırakmaz** (bunun referans aldığı her şey dahil).

Uzun süre çalışan bir sunucuda, bu sızıntılar sessizce birikir, kademeli olarak belleği tüketir ve hizmet performansı düşer veya çöker — ve anında bir hata olmadığından tespit etmek zordur.

Nedenleri (engellenen kanal işlemleri, eksik iptal etme) ve önlemeleri (**context tabanlı iptal etme** birincil savunma olarak, uygun kanal kapatma, arabelleğe alınmış kanallar, alıcıların sağlanması) anlamak, güvenilir eş zamanlı Go yazmak için gereklidir.

Tespit araçlarını bilmek (`runtime.NumGoroutine`, pprof, goleak) eşit derecede önemlidir.

Bu, üretim kalitesinde eş zamanlı Go yazabilen geliştiricileri, sürekli yük altında sızıntı yapan kod yazanlardan ayıran, kritik ve sıkça test edilen bir konudur.