死锁是多个goroutine因互相等待资源而无限阻塞的现象，常见于互斥锁的AB-BA循环等待或Channel无缓冲单向通信。解决方法包括统一加锁顺序、使用带缓冲Channel、select结合超时或default分支、确保WaitGroup的Add在Wait前完成，并避免sync.Once中初始化函数依赖外部锁。
Golang并发编程中的死锁，本质上是多个goroutine之间互相等待对方释放资源，从而导致所有相关goroutine无限期阻塞的现象。这通常发生在资源竞争、不当的同步机制或不完整的资源释放流程中，使得程序无法继续执行。理解其核心在于识别“循环等待”和“资源饥饿”的模式。
解决方案
要有效解决Golang并发编程中的死锁问题，我们首先需要深入理解其产生机制，然后才能对症下药。死锁并非单一原因造成，它往往是多种因素交织的产物，尤其在Go这种高度依赖goroutine和channel的语言中，其表现形式也更加多样。
死锁的经典条件通常包括：互斥（Mutual Exclusion）、请求与保持（Hold and Wait）、不可抢占（No Preemption）和循环等待（Circular Wait）。在Go语言的语境下，这些条件主要体现在互斥锁（
sync.Mutex
）、读写锁（
sync.RWMutex
）以及通道（
chan
）的使用上。
避免死锁的核心策略在于打破这四个条件中的至少一个。实践中，我们通常通过规范资源获取顺序、使用带缓冲的通道、设置超时机制或引入死锁检测机制来达成目标。我个人在开发过程中，最常遇到的还是Channel相关的死锁，尤其是初学者阶段，总觉得Channel是万能的，结果一不小心就写出了互相等待的逻辑。说实话，每次遇到死锁，那种程序卡住不动的感觉真是让人头大，调试起来也挺费劲的。
立即学习“go语言免费学习笔记（深入）”；
Golang中互斥锁（Mutex）是如何引发死锁的，我们又该如何避免？
互斥锁（
sync.Mutex
）是Go并发中最基础的同步原语之一，它的作用是确保同一时间只有一个goroutine能够访问某个共享资源。然而，不当使用它，恰恰是引发死锁的常见原因。
最直接的死锁场景是“自我死锁”：一个goroutine在持有锁的情况下，再次尝试获取同一个锁。这在Go中会直接导致程序panic，提示
fatal error: all goroutines are asleep - deadlock!
。虽然Go的运行时会检测到这种显而易见的错误，但更隐蔽的死锁则是由多个goroutine和多个锁之间的交互引起的。
考虑这样一个场景：goroutine A需要锁L1和L2，goroutine B也需要锁L1和L2。如果A先获取了L1，B先获取了L2，然后A尝试获取L2（而L2被B持有），B尝试获取L1（而L1被A持有），这就形成了经典的“AB-BA”死锁模式。两个goroutine都持有对方需要的资源，且都在等待对方释放资源，从而陷入无限等待。
// 这是一个模拟AB-BA死锁的简单示例package mainimport ( "fmt" "sync" "time")var ( lockA sync.Mutex lockB sync.Mutex)func workerA() { lockA.Lock() fmt.Println("Worker A acquired lockA") time.Sleep(100 * time.Millisecond) // 模拟一些工作 lockB.Lock() fmt.Println("Worker A acquired lockB") // ... do something with both locks lockB.Unlock() lockA.Unlock() fmt.Println("Worker A finished")}func workerB() { lockB.Lock() fmt.Println("Worker B acquired lockB") time.Sleep(100 * time.Millisecond) // 模拟一些工作 lockA.Lock() fmt.Println("Worker B acquired lockA") // ... do something with both locks lockA.Unlock() lockB.Unlock() fmt.Println("Worker B finished")}func main() { go workerA() go workerB() // 让主goroutine等待足够长的时间，以便死锁发生 time.Sleep(3 * time.Second) fmt.Println("Main goroutine exiting. If no output from workers, a deadlock occurred.")}
运行上述代码，你很可能会看到程序在打印了“Worker A acquired lockA”和“Worker B acquired lockB”之后就卡住了，最终Go运行时会报告死锁。
避免策略：
统一加锁顺序： 这是最核心也最有效的策略。如果所有goroutine在需要多个锁时，都按照相同的、预先定义好的顺序（例如，总是先L1再L2）来获取锁，那么“循环等待”的条件就被打破了。在上面的例子中，如果
workerB
也先尝试获取
lockA
，再获取
lockB
，那么死锁就不会发生。细粒度锁与大粒度锁的权衡： 尽量只锁住真正需要保护的资源，而不是整个结构体或函数。过度使用大粒度锁会增加资源竞争的可能性，从而提高死锁的风险。但过于细粒度的锁又会增加编程的复杂性，需要权衡。使用
defer
确保解锁： 虽然这不能直接避免死锁，但它能确保在函数返回时锁被释放，避免因忘记解锁而导致的资源泄露或后续死锁。这是并发编程中的一个好习惯。避免在持有锁时调用外部未知函数： 外部函数可能试图获取相同的锁，或者引入新的锁，从而打破你的加锁顺序约定，引入难以预料的死锁。
深入剖析Go语言中Channel死锁的常见场景与预防措施
从互斥锁的经典案例跳出来，我们再看看Go语言里更具特色的Channel。它虽然是并发利器，但用不好同样是死锁的温床。Channel的死锁通常发生在发送方和接收方互相等待，或者Channel容量不足以应对发送/接收速度时。
常见场景：
无缓冲Channel的单向阻塞：如果一个goroutine向一个无缓冲的Channel发送数据，而没有其他goroutine准备好接收，那么发送方就会永久阻塞。反之，如果一个goroutine从无缓冲Channel接收数据，而没有发送方，接收方也会永久阻塞。当整个程序中所有的goroutine都陷入这种等待时，死锁就发生了。
// 无缓冲Channel的单向阻塞死锁示例package mainimport ( "fmt" "time")func main() { ch := make(chan int) // 尝试向一个没有接收者的无缓冲channel发送数据 go func() { fmt.Println("Sender goroutine trying to send...") ch <- 1 // 永远阻塞 fmt.Println("Sender goroutine sent data.") // 这行不会被执行 }() // 如果没有接收者，或者接收者在发送者之后启动，且没有其他goroutine能继续执行 // 整个程序就会死锁 time.Sleep(time.Second) // 等待一下，让发送者有机会运行 fmt.Println("Main goroutine exiting. If no 'Sender goroutine sent data.' output, a deadlock occurred.") // 假设这里没有 ch <- 1 的接收者，或者接收者在别处也阻塞了}
运行这段代码，你会看到“Sender goroutine trying to send…”之后，程序就卡住了。
Channel链式死锁：多个goroutine通过Channel形成一个环形依赖。例如，goroutine A等待从Channel CA接收数据，而Channel CA的数据由goroutine B发送；goroutine B等待从Channel CB接收数据，而Channel CB的数据由goroutine A发送。这又是一个经典的循环等待。
select
语句的死锁：当一个
select
语句中的所有
case
都无法执行（例如，所有Channel都阻塞），并且没有
default
分支时，
select
语句会永久阻塞，如果所有goroutine都因此阻塞，就会导致死锁。
预防措施：
使用带缓冲的Channel： 对于发送方和接收方速度不匹配的场景，或者需要解耦发送和接收操作时，带缓冲的Channel能提供一定的弹性。它允许在没有即时接收者的情况下，发送方将数据放入缓冲区，避免立即阻塞。但要注意，缓冲区满或空时，仍然会阻塞。
// 使用带缓冲Channel避免上述死锁package mainimport ( "fmt" "time")func main() { ch := make(chan int, 1) // 缓冲大小为1的Channel go func() { fmt.Println("Sender goroutine trying to send...") ch <- 1 // 可以发送，因为有缓冲 fmt.Println("Sender goroutine sent data.") }() time.Sleep(100 * time.Millisecond) // 等待发送者运行 val := <-ch // 接收数据 fmt.Printf("Receiver got: %dn", val) fmt.Println("Main goroutine exiting.")}
这个例子中，由于有了缓冲，发送者可以成功发送数据，程序不会死锁。
select
语句结合
default
或超时：在
select
语句中加入
default
分支，可以防止在所有Channel都阻塞时无限等待。
default
分支会在没有其他Channel准备好时立即执行。
// 使用select和default避免死锁package mainimport ( "fmt" "time")func main() { ch := make(chan int) go func() { time.Sleep(2 * time.Second) // 模拟延迟发送 ch <- 1 }() select { case val := <-ch: fmt.Printf("Received: %dn", val) case <-time.After(1 * time.Second): // 设置超时 fmt.Println("Timeout! No data received within 1 second.") default: // 如果没有default，且ch阻塞，这里会死锁 fmt.Println("No data available right now, doing other work.") } time.Sleep(3 * time.Second) // 等待goroutine结束 fmt.Println("Main goroutine exiting.")}
这个例子中，如果在1秒内没有数据，
select
会执行超时分支或
default
分支，而不是死锁。
正确关闭Channel：关闭Channel是一个信号，表示不会再有数据发送。接收方可以通过
v, ok := <-ch
来判断Channel是否关闭。不正确地关闭或不关闭Channel可能导致接收方永久等待。通常，发送方负责关闭Channel，并且只关闭一次。
避免循环依赖：设计系统时，尽量避免goroutine之间形成环形的Channel依赖。如果必须存在，确保有明确的退出机制或超时机制来打破循环。
除了互斥锁和Channel，Golang并发中还有哪些隐蔽的死锁陷阱？
除了互斥锁和Channel，Go并发编程中还有一些不那么显眼，但同样能导致死锁的陷阱，这些往往与
sync
包的其他同步原语或不当的程序逻辑有关。
sync.WaitGroup
的误用：
WaitGroup
用于等待一组goroutine完成。它的死锁通常发生在以下两种情况：
Add()
在
Wait()
之后调用： 如果一个
WaitGroup
的计数器已经变为0，并且有goroutine正在
Wait()
，此时再调用
Add()
，可能会导致
Wait()
永远无法返回，因为
Done()
的调用次数可能永远无法再次达到
Add()
的预期。
Add()
和
Done()
不匹配：
Done()
的调用次数少于
Add()
的调用次数，那么
Wait()
会无限期等待。
// WaitGroup 误用导致的死锁package mainimport ( "fmt" "sync" "time")func main() { var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() fmt.Println("Worker 1 doing work...") time.Sleep(500 * time.Millisecond) }() // 假设这里有一些复杂的逻辑，导致在Wait()之后才Add() // 这通常是逻辑错误，但在实际项目中可能发生 // wg.Wait() // 如果在这里等待，那么下面的Add(1)会是问题 go func() { // 假设这个goroutine启动较晚，或在某个条件后才被Add time.Sleep(1 * time.Second) // 模拟延迟 wg.Add(1) // 错误：在其他goroutine可能已经Done()后又Add() defer wg.Done() fmt.Println("Worker 2 doing work...") }() fmt.Println("Main goroutine waiting for workers...") wg.Wait() // 可能永远等待，如果Worker 2的Add(1)发生在Worker 1 Done()之后 fmt.Println("All workers finished.")}
在这个例子中，如果
Worker 1
完成并调用
Done()
后，
wg
的计数器变为0，
Wait()
可能已经返回。但如果
Worker 2
的
Add(1)
在
Wait()
之后，或者
Wait()
在
Worker 1
Done()
和
Worker 2
Add(1)
之间，就可能导致问题。更典型的是，如果
wg.Add(1)
在
Wait()
之后执行，且之前计数器已经归零，
Wait()
将无法感知到新的
Add
，从而死锁。
避免策略： 确保所有
Add()
调用都在
Wait()
之前完成。一个常见的模式是在启动所有goroutine之前，一次性调用所有
Add()
。
资源获取顺序不一致导致的复杂死锁：这与互斥锁的AB-BA模式类似，但在更复杂的系统中，可能涉及多种资源（数据库连接、文件句柄、网络套接字等），而不仅仅是Go的同步原语。当多个goroutine需要获取多种不同类型的资源时，如果它们获取这些资源的顺序不一致，就可能形成循环等待。这其实是“哲学家就餐问题”的Go语言变体。
避免策略： 强制执行全局的资源获取顺序。这通常需要精心设计，并在代码审查中严格把控。
sync.Once
的自死锁：
sync.Once
用于确保某个操作只执行一次。如果
Do
方法内部的函数本身尝试获取一个锁，而这个锁又被
Do
方法外部的某个goroutine持有，并且这个外部goroutine又在等待
Do
方法完成，那么就会形成自死锁。这种情况比较罕见，但确实存在。
// sync.Once 自死锁示例package mainimport ( "fmt" "sync" "time")var ( once sync.Once mu sync.Mutex)func initFunc() { mu.Lock() // 尝试获取锁 fmt.Println("initFunc acquired mutex") // ... do initialization ... mu.Unlock() fmt.Println("initFunc released mutex")}func main() { mu.Lock() // 主goroutine先获取了mu fmt.Println("Main goroutine acquired mutex") go func() { fmt.Println("Goroutine trying to call once.Do...") once.Do(initFunc) // 这里的initFunc会尝试获取mu，但mu被主goroutine持有 fmt.Println("Goroutine finished once.Do.") }() time.Sleep(1 * time.Second) // 等待goroutine启动并阻塞 // 主goroutine如果在这里等待goroutine完成，且goroutine依赖mu，就死锁了 // 比如，如果主goroutine要等待一个channel信号，而这个信号只有在initFunc完成后才发送 fmt.Println("Main goroutine exiting. If no 'initFunc acquired mutex' output, a deadlock occurred.") mu.Unlock() // 如果主goroutine不释放，initFunc永远拿不到锁}
在这个例子中，如果主goroutine不释放
mu
，那么
initFunc
永远无法执行，
once.Do
也就永远无法完成，从而导致死锁。
避免策略：
sync.Once
的初始化函数应该是自包含的，不应该依赖外部可能被阻塞的资源。它应该只做一些简单的、无副作用的初始化工作。
总的来说，Go语言的并发原语强大而灵活，但这也意味着开发者需要对并发模式有更深入的理解。避免死锁的关键在于细致的资源管理、一致的加锁顺序、合理使用Channel以及对各种同步原语行为的精确把握。调试死锁虽然麻烦，但往往也是学习并发编程最深刻的经历之一。
以上就是Golang并发编程中常见的死锁(deadlock)原因和避免策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1401970.html
微信扫一扫 
支付宝扫一扫 
