死锁是多个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 main
import (
"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 main import ( "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 main import ( "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: %d\n", val) fmt.Println("Main goroutine exiting.") }这个例子中，由于有了缓冲，发送者可以成功发送数据，程序不会死锁。
-
select
语句结合default
或超时： 在select
语句中加入default
分支，可以防止在所有Channel都阻塞时无限等待。default
分支会在没有其他Channel准备好时立即执行。// 使用select和default避免死锁 package main import ( "fmt" "time" ) func main() { ch := make(chan int) go func() { time.Sleep(2 * time.Second) // 模拟延迟发送 ch <- 1 }() select { case val := <-ch: fmt.Printf("Received: %d\n", 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 main import ( "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 main import ( "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以及对各种同步原语行为的精确把握。调试死锁虽然麻烦，但往往也是学习并发编程最深刻的经历之一。
