Golang 中 Goroutine 泄漏的典型场景与修复方案

本文详解 go 并发编程中因通道未及时关闭或协程阻塞导致的 goroutine 泄漏问题，以 `same()` 函数为例，分析泄漏根源，并给出通过退出通道（quit channel）优雅终止协程的标准实践。

在 Go Tour 的二叉树遍历练习中，Same() 函数用于判断两棵二叉树是否包含完全相同的值序列（中序遍历结果一致）。初版实现看似简洁，却隐藏着严重的 Goroutine 泄漏（Goroutine leak） 问题：

func Same(t1, t2 *tree.Tree) bool {
    w1, w2 := make(chan int), make(chan int)
    go Walk(t1, w1) // 启动 goroutine 遍历 t1
    go Walk(t2, w2) // 启动 goroutine 遍历 t2

    for {
        v1, ok1 := <-w1
        v2, ok2 := <-w2
        if !ok1 || !ok2 {
            return ok1 == ok2
        }
        if v1 != v2 {
            return false // ⚠️ 提前返回！但 w1/w2 的 goroutine 仍在运行
        }
    }
}

? 泄漏根源：协程卡在发送阻塞，永不退出

关键在于 Walk() 的实现：

func Walk(t *tree.Tree, ch chan int) {
    walkImpl(t, ch)
    close(ch) // 仅当整棵树遍历完才关闭
}

而 walkImpl 是递归向 ch 发送节点值的：

func walkImpl(t *tree.Tree, ch chan int) {
    if t == nil { return }
    walkImpl(t.Left, ch)
    ch <- t.Value // ← 此处可能永久阻塞！
    walkImpl(t.Right, ch)
}

当两棵树不同时（例如 tree.New(1) vs tree.New(2)），Same() 会在第一次值不匹配时立即 return false。此时：

• 主 goroutine 退出，w1 和 w2 两个通道无人接收；
• 但 Walk 启动的两个 goroutine 仍在执行递归遍历，一旦尝试向已无接收者的 ch 发送值（如 ch 永久阻塞在发送操作上；
• 这两个 goroutine 永远无法结束，内存与栈资源持续占用——即典型的 Goroutine 泄漏。

可通过 runtime.NumGoroutine() 验证：连续调用 Same() 多次后，goroutine 数量会持续增长。

✅ 修复方案：引入退出通道（quit channel）

改进版使用 quit chan int 实现协作式取消（cooperative cancellation）：

func walkImpl(t *tree.Tree, ch, quit chan int) {
    if t == nil {
        return
    }
    walkImpl(t.Left, ch, quit)
    select {
    case ch <- t.Value:     // 正常发送
    case <-quit:            // 收到退出信号，立即返回
        return
    }
    walkImpl(t.Right, ch, quit)
}

func
 Same(t1, t2 *tree.Tree) bool {
    w1, w2 := make(chan int), make(chan int)
    quit := make(chan int)
    defer close(quit) // 函数返回时关闭 quit，通知所有 walk goroutine 退出

    go Walk(t1, w1, quit)
    go Walk(t2, w2, quit)

    for {
        v1, ok1 := <-w1
        v2, ok2 := <-w2
        if !ok1 || !ok2 {
            return ok1 == ok2
        }
        if v1 != v2 {
            return false // 此时 quit 已 close，walk goroutines 将快速退出
        }
    }
}

核心改进点：

• quit 通道在 Same() 函数退出时由 defer close(quit) 统一关闭；
• walkImpl 中使用 select 非阻塞检测 quit，一旦收到信号即终止递归；
• 所有 Walk goroutine 在 quit 关闭后数毫秒内完成清理，无资源残留。

? 注意事项与最佳实践

• 永远不要依赖“无人接收”来终止 goroutine：Go 中发送到无缓冲且无接收者的 channel 会永久阻塞。
• 显式取消优于隐式等待：对长生命周期或可能提前终止的 goroutine，务必设计退出机制（如 context.Context 或自定义 quit channel）。
• 优先使用 context.Context：现代 Go 代码推荐用 context.WithCancel 替代手写 quit channel，更符合生态规范。
• 测试泄漏：可通过 pprof 或 runtime.NumGoroutine() + 压力测试验证修复效果。

Goroutine 泄漏不易察觉，但累积后会导致内存暴涨、GC 压力增大甚至服务不可用。理解其成因并建立防御性并发习惯，是写出健壮 Go 服务的关键一步。