Что вызывает утечки горутин и как их предотвратить?

Question

Accepted Answer

**Утечка горутины** — это горутина, которая никогда не завершается — она остаётся заблокированной или работает вечно, потребляя память (и держа в живых её referenced объекты) всё время работы программы. Поскольку горутины дёшевы в запуске, их легко "утечь", и утечки накапливаются незаметно, пока сервис не деградирует или не исчерпает память.

## Причина 1: блокировка на канале без отправителя/получателя

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

Горутина, заблокированная на отправку/получение из канала, которая никогда не завершится, будет ждать **вечно** — она никогда не будет удалена сборщиком мусора, потому что технически всё ещё "работает".

## Причина 2: отсутствие отмены / сигнала завершения

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

## Предотвращение 1: используйте context для отмены

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

Дача каждой долгоживущей горутине возможности быть отменённой (`<-ctx.Done()`) — основная защита — она гарантирует, что горутины завершаются, когда их работа больше не нужна.

## Предотвращение 2: используйте буферизованные каналы или убедитесь в наличии получателей

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

## Предотвращение 3: всегда закрывайте каналы / правильно их осушайте

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

## Обнаружение утечек

```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()` (постоянно растущее число сигнализирует об утечке), проверка дампов горутин через `pprof` и использование `goleak` в тестах — основные инструменты обнаружения.

## Почему это важно

Утечки горутин — одна из наиболее частых и коварных проблем в production Go сервисах.

Потому что горутины настолько дёшевы в запуске, разработчики создают их свободно — но горутина, заблокированная навечно (на канале без контрагента или в бесконечном цикле без отмены), **никогда не завершится и никогда не освободит свою память** (включая всё, на что она ссылается).

В долгоживущем сервере эти утечки накапливаются незаметно, постепенно потребляя память, пока сервис не деградирует или не упадёт — и их трудно заметить, потому что нет немедленной ошибки.

Понимание причин (заблокированные операции с каналом, отсутствие отмены) и способов предотвращения (**отмена на основе context** как основная защита, правильное закрытие каналов, буферизованные каналы, гарантия наличия получателей) критично для написания надёжного параллельного Go.

Знание инструментов обнаружения (`runtime.NumGoroutine`, pprof, goleak) не менее важно.

Это критическая, часто тестируемая тема, которая отделяет разработчиков, способных писать production-grade параллельный Go, от тех, кто пишет код, который "течёт" под нагрузкой.