Golang并发编程中常见的死锁(deadlock)原因和避免策略-Golang-PHP中文网

死锁是多个goroutine因互相等待资源而无限阻塞的现象，常见于互斥锁的AB-BA循环等待或Channel无缓冲单向通信。解决方法包括统一加锁顺序、使用带缓冲Channel、select结合超时或default分支、确保WaitGroup的Add在Wait前完成，并避免sync.Once中初始化函数依赖外部锁。

golang并发编程中常见的死锁(deadlock)原因和避免策略

Golang并发编程中的死锁，本质上是多个goroutine之间互相等待对方释放资源，从而导致所有相关goroutine无限期阻塞的现象。这通常发生在资源竞争、不当的同步机制或不完整的资源释放流程中，使得程序无法继续执行。理解其核心在于识别“循环等待”和“资源饥饿”的模式。

解决方案

要有效解决Golang并发编程中的死锁问题，我们首先需要深入理解其产生机制，然后才能对症下药。死锁并非单一原因造成，它往往是多种因素交织的产物，尤其在Go这种高度依赖goroutine和channel的语言中，其表现形式也更加多样。

死锁的经典条件通常包括：互斥（Mutual Exclusion）、请求与保持（Hold and Wait）、不可抢占（No Preemption）和循环等待（Circular Wait）。在Go语言的语境下，这些条件主要体现在互斥锁（

sync.Mutex

登录后复制

）、读写锁（

sync.RWMutex

登录后复制

）以及通道（

chan

登录后复制

）的使用上。

避免死锁的核心策略在于打破这四个条件中的至少一个。实践中，我们通常通过规范资源获取顺序、使用带缓冲的通道、设置超时机制或引入死锁检测机制来达成目标。我个人在开发过程中，最常遇到的还是Channel相关的死锁，尤其是初学者阶段，总觉得Channel是万能的，结果一不小心就写出了互相等待的逻辑。说实话，每次遇到死锁，那种程序卡住不动的感觉真是让人头大，调试起来也挺费劲的。

立即进入“豆包AI人工智官网入口”；

立即学习“豆包AI人工智能在线问答入口”；

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都因此阻塞，就会导致死锁。

预防措施：

豆包AI编程

豆包推出的AI编程助手

483

查看详情

使用带缓冲的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不释放