死锁主因是协程相互等待资源，如无缓冲channel收发不匹配、循环等待、错误关channel或锁顺序不一致；应使用缓冲channel解耦、明确channel生命周期、select超时机制及统一锁顺序，优先用channel通信替代共享内存，遵循“谁发送谁关闭”原则，可有效避免死锁。
在Go语言的并发编程中，死锁（Deadlock）是指多个协程相互等待对方释放资源，导致程序无法继续执行。虽然Go的goroutine和channel设计简化了并发控制，但如果使用不当，依然可能引发死锁。避免死锁的关键在于理解其成因并遵循良好的编程实践。
理解死锁的常见场景
Go中的死锁通常出现在以下几种情况：
- 向无缓冲channel发送数据但无人接收：比如创建了一个无缓冲channel，一个goroutine尝试发送数据，但没有其他goroutine准备接收，发送会一直阻塞，最终主程序结束前触发死锁检测。
- 循环等待channel操作：多个goroutine相互等待彼此的channel通信，形成闭环依赖。
- 错误地关闭或重复关闭channel：对已关闭的channel进行发送操作会panic，而对只读channel关闭则编译报错；更隐蔽的问题是goroutine因等待已关闭但无数据的channel而阻塞。
- 使用互斥锁时嵌套加锁或顺序不一致：多个goroutine以不同顺序获取多个mutex，容易造成相互等待。
使用带缓冲channel合理解耦
无缓冲channel是同步的，发送和接收必须同时就绪。若无法保证接收方就绪，可考虑使用带缓冲channel来解耦生产和消费过程。
例如：ch := make(chan int, 2) ch <- 1 ch <- 2 // 不会立即死锁，因为缓冲允许暂存
注意：缓冲只是缓解压力，并不能根除逻辑上的等待问题。仍需确保最终有goroutine从channel取数据。
立即学习“go语言免费学习笔记（深入）”；
确保channel有明确的收发方和生命周期
每个channel应有清晰的“所有者”——通常是创建它的goroutine负责关闭，而接收方不应尝试关闭。遵循“谁发送，谁关闭”的原则可以减少混乱。
- 使用
for-range遍历channel，自动处理关闭信号。 - 用
select配合default或超时机制避免永久阻塞。 - 对可能长时间无数据的channel，设置超时判断是否异常。
select {
case data := <-ch:
fmt.Println("收到:", data)
case <-time.After(3 * time.Second):
fmt.Println("超时，可能出错")
}
避免锁的循环等待
当使用sync.Mutex保护共享资源时，多个锁的获取顺序必须一致。
- 如果goroutine A 先锁 lock1 再锁 lock2，那么所有涉及这两个锁的操作都应保持相同顺序。
- 考虑将多个相关状态封装到一个结构体中，用单一锁保护，减少锁的数量。
- 优先使用channel传递数据而非共享内存，这是Go推崇的并发哲学：“不要通过共享内存来通信，通过通信来共享内存”。
基本上就这些。只要注意channel的收发配对、合理使用缓冲与超时、规范锁的使用顺序，并尽量用channel代替共享变量，就能大幅降低死锁风险。Go运行时会在程序卡死时提示“fatal error: all goroutines are asleep - deadlock”，帮助定位问题，但最好的方式是在设计阶段就规避隐患。
