Golang并发程序中常见死锁场景分析

Go中典型死锁是channel操作未配对：向无缓冲channel发送时无人接收，或接收时无人发送，运行时panic提示“all goroutines are asleep - deadlock!”。

channel 操作未配对导致的死锁

Go 中最典型的死锁，就是 goroutine 在向无缓冲 channel 发送数据时阻塞，且没有其他 goroutine 从该 channel 接收；或从 channel 接收时阻塞，但无人发送。编译器无法静态检测这类逻辑死锁，运行时 panic 提示为 fatal error: all goroutines are asleep - deadlock!。

常见诱因：

• 在主 goroutine 中直接 ch ，而接收逻辑被错误地放在另一个未启动的 goroutine 里
• 用 select 读 channel 时漏写 default，且 channel 暂时空
• 关闭 channel 后仍尝试发送（会 panic），但更隐蔽的是：关闭后继续接收——这本身不 panic，但若接收方没感知关闭，可能卡在循环中等不到新数据

func main() {
    ch := make(chan int)
    ch <- 42 // 死锁：主 goroutine 卡在这里，无其他 goroutine 接收
}

sync.Mutex 或 sync.RWMutex 重复加锁

sync.Mutex 不可重入。同一个 goroutine 连续两次调用 mu.Lock() 会导致永久阻塞——它不会报错，也不会超时，只会卡死。

容易踩坑的场景：

立即学习“go语言免费学习笔记（深入）”；

• 方法内部调用自身（递归）且都持锁
• 组合结构体嵌套调用不同方法，各自独立加锁，但实际共享同一把锁
• defer mu.Unlock() 写在函数开头而非临界区结尾，导致解锁时机错误

func (s *Service) DoWork() {
    s.mu.Lock()
    defer s.mu.Unlock() // 错：这里 defer 的是第一次 Lock 对应的 Unlock
    s.mu.Lock()         // 死锁：第二次 Lock 永远等不到释放
    // ...
}

WaitGroup 使用不当引发的等待僵局

sync.WaitGroup 本身不直接导致死锁，但误用会让主 goroutine 永远等待不存在的完成信号。

典型错误：

• wg.Add(1) 在 goroutine 启动之后才调用（竞态，Add 可能被跳过）
• goroutine 中忘记调用 wg.Done()，或因 panic 未执行到（应配合 defer）
• 在循环中反复创建新 WaitGroup 实例，却对旧实例调用 Wait()

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 3; i++ {
        go func() {
            // wg.Add(1) 漏了！下面 wg.Wait() 将立即返回，或更糟：如果 wg 已 Add 过但没 Done，就永远等
            time.Sleep(time.Second)
            // wg.Done() 也漏了
        }()
    }
    wg.Wait() // 可能立刻返回（wg 计数为 0），也可能死锁（若某处误 Add 但没 Done）
}

select + timer 组合中的隐式阻塞

看似安全的 select 如果只包含带 time.After 的 case，且没有 default 或其它可就绪 channel，仍可能因 timer 未触发而长期挂起——这不是死锁（runtime 能识别），但行为等效于“逻辑卡住”。

真正危险的是：timer 和 channel 共存时，误认为 “只要 timer 到了就一定走 default”，其实 select 是随机选择多个就绪 case 的，若 channel 恰好在此刻就绪，timer 就被跳过了。

• 依赖 time.After 做超时，但未用 case + case 配对，而是单独启动 goroutine 写 channel，主逻辑只等 timer——这不算死锁，但业务会丢数据
• 在循环中反复创建新 timer，却不 stop，造成 goroutine 泄漏+资源耗尽，间接诱发调度延迟甚至疑似死锁

select {
case msg := <-dataCh:
    handle(msg)
case <-time.After(5 * time.Second):
    log.Println("timeout") // 正确用法：与 channel case 并列
}

死锁往往不是单点错误，而是多个同步原语在时序和所有权上的错配。调试时别只盯 panic 信息，先确认所有 channel 是否有确定的发送/接收端、所有锁是否成对出现、所有 WaitGroup 的 Add/Done 是否严格对应——尤其注意那些“本该执行却没执行”的 defer 或 done。