Go并发编程为什么会发生死锁_Go死锁问题分析

死锁根本原因是所有goroutine均阻塞且无人可唤醒，运行时直接panic；for range ch卡死主因是通道未关闭，无缓冲channel收发必须同步就位。

Go并发编程中发生死锁，根本原因只有一个：所有goroutine都阻塞在同步原语上，且无人能唤醒它们。这不是程序“慢了”，而是运行时直接 panic 报错：fatal Error: all goroutines are asleep - deadlock!。它不靠竞态检测触发，也不依赖超时——只要调度器发现没有一个 goroutine 处于 runnable 状态，就立刻终止程序。

为什么 for range ch 会卡死？——通道未关闭是最常见诱因

当你写 for v := range ch { ... }，Go 实际执行的是“持续接收直到 ch 被关闭”。如果没人调用 close(ch)，这个循环就永远等下去。

• Walk 递归遍历完树后不会自动关 channel，这是设计使然（避免多处 close 引发 panic）
• 主 goroutine 卡在 range ch1，而发送 goroutine 已退出，ch1 永远没被 close → 无其他 goroutine 可推进 → 死锁
• 哪怕只漏关一个 channel（比如只关 ch1 没关 ch2），只要主逻辑还依赖另一个未关的 channel，照样死锁

向无缓冲 channel 发送却没人收，是“秒级死锁”

无缓冲 channel 的收发必须“同时就位”。下面这段代码运行即死锁：

func main() {     ch := make(chan int)     ch <- 1>
 
没有其他 goroutine 启动并执行 ，发送操作就永远无法完成 
 
带缓冲 channel（如 make(chan int, 1)）可暂存数据，但缓冲区满后仍会阻塞，本质相同
 
解决思路不是“加缓冲”，而是明确通信契约：谁发、谁收、何时收完
 
 
锁嵌套顺序不一致，是隐蔽的死锁温床
 
两个 goroutine 分别按不同顺序获取两把互斥锁，极易形成循环等待：
go func() {     mu1.Lock()     time.Sleep(10 * time.Millisecond)     mu2.Lock() // 等 mu2     mu2.Unlock()     mu1.Unlock() }() go func() {     mu2.Lock()     time.Sleep(10 * time.Millisecond)     mu1.Lock() // 等 mu1 → 死锁！     mu1.Unlock()     mu2.Unlock() }()

goroutine A 持 mu1 等 mu2，B 持 mu2 等 mu1 
这种死锁不会被 go run -race 捕获，因为不涉及数据竞争，只涉及逻辑等待
预防方法：全局约定锁获取顺序（如总是先 mu1 后 mu2），或改用 channel 通信代替共享内存

真正难排查的不是“明显卡住”的场景，而是那些看似合理、实则缺少退出条件的循环——比如用 select {} 等待多个 channel 却忘了关其中任何一个，或者用 sync.WaitGroup 但 Done() 调用次数少了一次。死锁从不预告，它只在所有路都被堵死时，才亮出那行红色错误。