本文详解 go 并发编程中因未关闭通道导致的典型死锁错误，以 `tree.walk` 和 `same` 函数为例，说明如何通过显式关闭通道、使用带接收状态的通道读取等手法安全实现树遍历与结构比较。
在 Go 的并发模型中，通道（channel）是 Goroutine 间通信的核心机制，但其行为也隐含着关键约束：从一个未关闭且已空的通道读取会永久阻塞。你遇到的 fatal error: all goroutines are asleep - deadlock! 正源于此。
回顾你的 Same 函数：
func Same(t1, t2 *tree.Tree) bool {
ch1 := make(chan int)
ch2 := make(chan int)
go Walk(t1, ch1)
go Walk(t2, ch2)
for i := range ch1 { // ⚠️ 死锁源头：ch1 永远不会关闭！
if i != <-ch2 {
return false
}
}
return true
}Walk 是一个递归中序遍历函数，它向通道发送所有节点值，但从未关闭通道。因此，for i := range ch1 会一直等待 ch1 关闭——而由于没有 Goroutine 负责关闭它，该循环永远无法退出。此时两个 Walk Goroutine 已执行完毕并退出，主 Goroutine 却卡在 range ch1 上，整个程序陷入“所有 Goroutine 都休眠”的死锁状态。
✅ 正确解法：在 Walk 执行完成后显式关闭通道。推荐使用匿名 Goroutine 封装调用，确保关闭逻辑与发送逻辑配对：
func Same(t1, t2 *tree.Tree) bool {
ch1 := make(chan int)
ch2 := make(chan int)
// 启动遍历并自动关闭通道
go func() {
Walk(t1, ch1)
close(ch1) // ✅ 关键：遍历结束即关闭
}()
go func() {
Walk(t2, ch2)
close(ch2) // ✅ 同样关闭 ch2，避免潜在风险
}()
// 安全比对：检查双方是否同步耗尽
for v1 := range ch1 {
v2, ok := <-ch2
if !ok || v1 != v2 {
return false
}
}
// 确保 ch2 也已读完（防止 t2 更长）
_, ok := <-ch2
return !ok // 若 ch2 还有剩余值，则返回 false
}? 关键要点总结：
- range ch 仅在通道被关闭后才退出；未关闭的通道会导致无限等待。
- 不要依赖“发送端 Goroutine 自动退出”来释放通道——必须显式 close(ch)。
- 使用
- 本例中 tree.New(1) 生成的是含 10 个节点的平衡二叉搜索树（值为 1~10），但切勿硬编码循环次数（如 for i ——这违反抽象原则，且在树结构变化时失效。
最终，完整的可运行示例应包含 main 函数与必要的导入：
package main
import (
"fmt"
"golang.org/x/tour/tree"
)
func Walk(t *tree.Tree, ch chan int) {
if t != nil {
Walk(t.Left, ch)
ch <- t.Value
Walk(t.Right, ch)
}
}
func Same(t1, t2 *tree.Tree) bool {
ch1, ch2 := make(chan int), make(chan int)
go func() { Walk(t1, ch1); close(ch1) }()
go func() { Walk(t2, ch2); close(ch2) }()
for v1 := range ch1 {
v2, ok := <-ch2
if !ok || v1 != v2 {
return false
}
}
_, ok := <-ch2
return !ok
}
func main() {
fmt.Println(Same(tree.New(1), tree.New(1))) // true
fmt.Println(Same(tree.New(1), tree.New(2))) // false
}遵循这一模式，你不仅能修复死锁，更能建立起对 Go 通道生命周期管理的坚实直觉——这是写出健壮并发程序的基石。
