ゴルーチンリークの原因は何か、そしてどのようにしてそれを防ぐのか？

Question

Accepted Answer

**ゴルーチンリーク**は、終了しないゴルーチンのことです。ブロック状態または無限に実行され、プログラムのライフタイム全体でメモリを消費し（また参照されるオブジェクトをメモリに保持し続け）ます。ゴルーチンは起動に最小限のコストしかかからないため、それらをリークさせるのは簡単であり、リークはサイレントに蓄積され、サービスの性能低下またはメモリ枯渇に至ります。

## 原因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: キャンセレーションのためにコンテキストを使用する

```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`の使用が主な検出ツールです。

## なぜ重要なのか

ゴルーチンリークは、本番環境のGoサービスで最も一般的で最も厄介な問題の1つです。

ゴルーチンは起動コストが非常に低いため、開発者はそれらを自由に作成します。しかし、永遠にブロック状態にあるゴルーチン（相手がないチャネル上でブロックされている、またはキャンセレーションなしの無限ループ内）は**決して終了せず、そのメモリを解放しません**（それが参照するすべてのものを含む）。

長時間実行されるサーバーでは、これらのリークはサイレントに蓄積され、メモリを徐々に消費していき、サービスの性能低下またはクラッシュに至ります。そしてそれらは即座のエラーがないため、検出が難しいのです。

原因（ブロック状態のチャネル操作、キャンセレーションの欠落）と予防策（主な防御としての**コンテキストベースのキャンセレーション**、適切なチャネルのクローズ、バッファ付きチャネル、受信元の確保）を理解することは、信頼できる並行処理Goコードを書くために不可欠です。

検出ツール（`runtime.NumGoroutine`、pprof、goleak）を知ることも同様に重要です。

これは、持続的な負荷の下でメモリリークがないコードを書く開発者と、そうでない開発者を区別する、重要でありしばしば出題される話題です。