死锁是因goroutine间循环等待资源导致的程序停滞，需通过统一加锁顺序、使用带缓冲通道或select超时机制来预防，结合go vet和堆栈分析定位问题。
Golang并发编程中的死锁，本质上是多个goroutine因争夺资源而相互等待，最终导致程序停滞。识别和解决这类问题，关键在于理解死锁发生的条件，并运用Go语言提供的同步原语（如
sync.Mutex、
chan）以及一些调试技巧来规避或定位问题，核心思想是打破循环等待或设置合理的超时机制。
死锁的发生，往往离不开几个经典条件：互斥（资源不能共享）、占有并等待（持有资源并请求新资源）、不可剥夺（资源不能被强制回收）以及循环等待（形成资源请求环）。在Go里，我们最常遇到的，往往是因不恰当的资源访问顺序或通道操作而导致的循环等待。
解决死锁，首先要从设计层面入手。我个人倾向于“防患于未然”，即在编码时就尽量避免死锁的潜在条件。
一个常见的陷阱是互斥锁（sync.Mutex
）的错误使用。Go的
sync.Mutex是非可重入的，这意味着同一个goroutine不能对同一个互斥锁进行两次
Lock()操作。一旦发生，第二次
Lock()就会永远阻塞，导致死锁。解决办法很简单，避免这种模式，或者考虑使用更高级的同步原语（如果业务逻辑确实需要，但通常Go里不推荐自定义可重入锁，而是重构逻辑）。
立即学习“go语言免费学习笔记（深入）”；
通道（chan
）的滥用或误用也是死锁的温床。一个无缓冲通道，如果发送方在没有接收方准备好时发送，或接收方在没有发送方准备好时接收，都会阻塞。如果双方都互相等待对方，那就死锁了。我的经验是，对于可能存在发送/接收时序不确定性的场景，考虑使用带缓冲通道，或者结合
select语句和
time.After实现超时机制。例如：
select {
case <-ch:
// 成功接收
case <-time.After(5 * time.Second):
// 超时处理
}这能有效打破无限等待的僵局。
另一个微妙的死锁场景是多锁的获取顺序不一致。假设goroutine A先获取锁L1再获取锁L2，而goroutine B先获取锁L2再获取锁L1，那么在特定时机下，它们就可能相互持有对方所需的锁，形成循环等待。这就像两辆车在十字路口都想左转，却都堵住了对方的去路。我的建议是，在涉及多个互斥锁的系统中，始终保持一致的加锁顺序，这是一个简单却极其有效的策略。
sync.WaitGroup
的误用也值得警惕。比如，在所有
Add操作完成之前就开始
Wait，或者
Done的数量少于
Add的数量，都可能导致
Wait永远阻塞。确保
Add在所有worker goroutine启动前完成，并且每个worker结束后都正确调用
Done。
识别死锁则需要一些工具和技巧。
-
go vet
可以在编译前发现一些明显的死锁模式，比如select {}这种永远阻塞的结构。 -
运行时诊断：当程序卡住时，按下
Ctrl+\
（或发送SIGQUIT
信号）可以打印出所有goroutine的堆栈信息。仔细分析这些堆栈，你会发现哪些goroutine处于chan receive
、chan send
、semacquire
（互斥锁等待）等
