Go语言死锁避免技巧详解

Go 语言中的死锁是程序彻底卡死的致命错误，表现为“fatal error: all goroutines are asleep - deadlock!”，一旦触发即不可恢复；最常见诱因是向无缓冲 channel 发送数据时缺乏对应的接收方——例如在 main 协程中直接写入却未启动读取协程，导致立即阻塞并引发全局死锁；这类问题虽易复现，却常因依赖特定条件而难以定位，掌握 channel 使用原则与调试技巧对构建健壮并发程序至关重要。

Go 运行时会在所有 goroutine 都阻塞且无法唤醒时 panic 报 fatal error: all goroutines are asleep - deadlock!，这不是可恢复错误，而是程序已彻底卡死。它不难复现，但排查成本高——尤其当死锁只在特定数据流或压力下触发时。

无缓冲 channel 发送没人接收就立刻死锁

这是新手最常踩的坑：在 main 协程里直接向无缓冲 channel 写数据，又没起另一个 goroutine 去读。

• 错误写法：ch := make(chan int); ch —— 语句卡住，后续代码永不执行，运行时立刻 panic
• 正确做法：要么用带缓冲 channel（make(chan int, 1)），要么确保发送和接收在不同 goroutine 中配对
• 注意：哪怕只差一行 go func() { fmt.Println(，顺序错位也会导致死锁（比如先 ch 再起 goroutine）

range 通道前忘了 close 就等同于无限等待

for v := range ch 的语义是“一直收，直到 ch 被关闭”。如果发送方 goroutine 已退出，但没调 close(ch)，主 goroutine 就永远停在这儿。

• 典型场景：树遍历、分片求和、多路结果聚合 —— 所有发送逻辑结束，但没人负责关 channel
• 安全模式：用匿名 goroutine 封装发送 + close()，例如 go func() { Walk(t, ch); close(ch) }()
• 别依赖 defer close(ch)：如果函数提前 return，defer 不会执行；也别在多个 goroutine 里 close 同一个 channel，会 panic

select 没写 default 或 timeout 就等于主动找死锁

select 本身不提供超时，它只是“等任意一个 case 就绪”。如果所有 channel 都阻塞，又没 default 分支，就会永久挂起。

• 常见误用：在 for 循环里反复 select { case ，但 done 可能永远不会被 close
• 修复方式：加 default（非阻塞轮询）或 case （带超时）
• 更健壮的做法是结合 context.Context：用 ctx.Done() 替代裸 channel，天然支持取消和超时

sync.Mutex 多把锁顺序不一致必然 AB-BA 死锁

两个 goroutine 分别按不同顺序获取两把锁，是经典的循环等待。Go 运行时无法检测这种局部死锁，程序会静默卡住（CPU 归零，goroutine 数稳定但不下降）。

• 例子：goroutine A 先 lock mu1 再 try lock mu2；goroutine B 反过来，先 mu2 后 mu1
• 解法不是加更多锁，而是约定顺序：比如始终按变量地址升序加锁（if &mu1 ），或用单个锁保护多个资源
• 警惕嵌套调用：函数 A 拿了 mu1 后调函数 B，B 又去拿 mu2 —— 表面看没冲突，实际可能和别的 goroutine 构成循环

真正难防的不是 panic 式死锁，而是那些不报错、不占 CPU、goroutine 数缓慢上涨的“隐性死锁”：某个 goroutine 在 channel 上永久等待，但它的发送/接收逻辑被条件分支跳过了，或者 context 已 cancel 却没检查 ctx.Err()。这类问题必须靠 runtime.NumGoroutine() 监控 + go tool trace 抓阻塞点，光看代码很难发现。

本篇关于《Go语言死锁避免技巧详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！