What causes goroutine leaks and how do you prevent them?

Question

Accepted Answer

A **goroutine leak** is a goroutine that never terminates — it stays blocked or running forever, consuming memory (and keeping its referenced objects alive) for the program's lifetime. Since goroutines are cheap to start, it's easy to leak them, and leaks accumulate silently until the service degrades or runs out of memory.

## Cause 1: blocked on a channel with no sender/receiver

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

A goroutine blocked on a channel send/receive that never completes will wait **forever** — it never gets garbage collected because it's technically still "running."

## Cause 2: no cancellation / done signal

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

## Prevention 1: use context for cancellation

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

Giving every long-lived goroutine a way to be cancelled (`<-ctx.Done()`) is the primary defense — it ensures goroutines terminate when their work is no longer needed.

## Prevention 2: use buffered channels or ensure receivers

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

## Prevention 3: always close channels / drain them properly

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

## Detecting leaks

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

Monitoring `runtime.NumGoroutine()` (a steadily climbing count signals a leak), inspecting goroutine dumps via `pprof`, and using `goleak` in tests are the main detection tools.

## Why it matters

Goroutine leaks are one of the most common and insidious problems in production Go services.

Because goroutines are so cheap to launch, developers create them freely — but a goroutine blocked forever (on a channel with no counterpart, or in an infinite loop with no cancellation) **never terminates and never releases its memory** (including everything it references).

In a long-running server, these leaks accumulate silently, gradually consuming memory until the service degrades or crashes — and they're hard to spot because there's no immediate error.

Understanding the causes (blocked channel operations, missing cancellation) and the preventions (**context-based cancellation** as the primary defense, proper channel closing, buffered channels, ensuring receivers) is essential for writing reliable concurrent Go.

Knowing the detection tools (`runtime.NumGoroutine`, pprof, goleak) is equally important.

This is a critical, frequently-tested topic that separates developers who can write production-grade concurrent Go from those who write code that leaks under sustained load.