3. Goroutine 泄漏：泄漏的常见原因与检测工具

Goroutine 泄漏是 Go 高并发生产环境中最隐蔽、破坏性最大的问题之一。泄漏的 goroutine 永远不会退出，持续占用栈内存（初始 2KB，可增长至 1GB）并持有堆引用，最终导致内存耗尽、GC 压力飙升、服务雪崩。本节从泄漏的三大根因出发，结合检测工具，帮助你建立从“预防”到“发现”再到“修复”的完整闭环。

3.1 泄漏的三大常见原因

根据生产环境事故统计，超过 85% 的 goroutine 泄漏可归因于以下三类模式。下表从根因、典型场景、风险等级三个维度进行对比：

3.1.1 死循环泄漏

死循环是最直接的泄漏形式。goroutine 内部循环缺少正确的退出信号，导致该 goroutine 永远无法结束。以下是最常见的两种变体：

// 变体1：for-range 通道未关闭导致永久阻塞
func leakByUnclosedChan() {
    ch := make(chan int)
    go func() {
        for v := range ch {  // ch 从未 close，循环永不退出
            fmt.Println(v)
        }
    }()
    ch <- 1
    // 忘记 close(ch)
}

// 变体2：select 无 default 且所有 case 永久阻塞
func leakBySelectBlock() {
    ch1 := make(chan int)
    ch2 := make(chan int)
    go func() {
        select {
        case <-ch1:  // 永远不会收到数据
        case <-ch2:  // 永远不会收到数据
        }
    }()
    // 两个 channel 都没有发送者，goroutine 永久阻塞
}

3.1.2 Channel 阻塞泄漏

Channel 阻塞泄漏发生在 goroutine 向通道发送数据或从通道接收数据时，对应的操作方不存在或已退出。无缓冲通道和有缓冲通道的阻塞条件不同：

// 典型泄漏：无缓冲通道发送阻塞
func leakByChanSend() {
    ch := make(chan int)
    go func() {
        ch <- 42  // 没有接收者，永久阻塞
    }()
    // 主 goroutine 未从 ch 接收数据
    time.Sleep(time.Second)
}

// 修复方案：使用 select + default 或带超时的发送
func safeSend(ch chan int, val int) bool {
    select {
    case ch <- val:
        return true
    case <-time.After(3 * time.Second):
        return false  // 超时后返回，避免泄漏
    }
}

3.1.3 Timer 未释放泄漏

Go 标准库的 time.After、time.NewTicker、time.NewTimer 如果使用不当，会导致底层 goroutine 泄漏。每次调用 time.After 都会创建一个新的 time.Timer，其内部 goroutine 在 timer 到期前不会退出。

// 泄漏版本：每次循环创建新 timer，且未及时释放
func leakByTimer() {
    for {
        select {
        case <-time.After(1 * time.Second):  // 每次迭代创建新 timer
            fmt.Println("tick")
        }
    }
}

// 正确版本：复用 timer，并在退出时 Stop
func safeTimer() {
    ticker := time.NewTicker(1 * time.Second)
    defer ticker.Stop()  // 确保函数退出时释放

    for i := 0; i < 5; i++ {
        <-ticker.C
        fmt.Println("tick", i)
    }
}

3.2 泄漏检测工具

手动审查代码难以发现所有泄漏，必须借助工具进行自动化检测。生产环境推荐“pprof 在线采样 + leaktest 单元测试”的组合策略。

3.2.1 pprof：生产级实时检测

pprof 是 Go 内置的性能分析工具，通过 goroutine 分析可以直观看到所有 goroutine 的堆栈信息。泄漏的 goroutine 通常表现为：数量持续增长、堆栈停留在同一位置、且不响应取消信号。

// 在 main.go 中启动 pprof HTTP 服务
import (
    "net/http"
    _ "net/http/pprof"
)

func main() {
    go func() {
        log.Println(http.ListenAndServe(":6060", nil))
    }()
    // ... 业务代码
}

// 命令行采集 goroutine 堆栈
// go tool pprof http://localhost:6060/debug/pprof/goroutine

// 在 pprof 交互界面中：
// (pprof) top  - 查看 goroutine 数量最多的堆栈
// (pprof) traces - 查看所有 goroutine 的完整堆栈
// (pprof) web  - 生成 SVG 调用图

下图展示了 pprof 检测 goroutine 泄漏的典型工作流程：

3.2.2 leaktest：单元测试级精准检测

leaktest 是 Uber 开源的 goroutine 泄漏检测库，在单元测试结束时检查是否有 goroutine 泄漏。它通过对比测试开始和结束时的 goroutine 列表来发现泄漏。

// 安装：go get -u go.uber.org/goleak

// 使用示例
import (
    "testing"
    "go.uber.org/goleak"
)

func TestMyFunction(t *testing.T) {
    defer goleak.VerifyNone(t)  // 测试结束时检查泄漏

    // 被测代码
    go func() {
        time.Sleep(10 * time.Second)  // 泄漏：goroutine 未在测试结束前退出
    }()
}

// 运行测试
// go test -v -run TestMyFunction
// 输出：goleak: Errors on goroutine 5: found unexpected goroutine

3.3 泄漏检测对比总结

两种工具各有侧重，生产环境应组合使用：