登录
首页 >  Golang >  Go教程

Golang并发死锁原因与解决方法

时间：2025-08-30 12:15:42 479浏览 收藏

小伙伴们有没有觉得学习Golang很有意思？有意思就对了！今天就给大家带来《Golang并发死锁原因及避免方法》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

死锁是多个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是万能的，结果一不小心就写出了互相等待的逻辑。说实话，每次遇到死锁，那种程序卡住不动的感觉真是让人头大，调试起来也挺费劲的。

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运行时会报告死锁。

避免策略：

  1. 统一加锁顺序： 这是最核心也最有效的策略。如果所有goroutine在需要多个锁时，都按照相同的、预先定义好的顺序（例如，总是先L1再L2）来获取锁，那么“循环等待”的条件就被打破了。在上面的例子中，如果workerB也先尝试获取lockA，再获取lockB，那么死锁就不会发生。
  2. 细粒度锁与大粒度锁的权衡： 尽量只锁住真正需要保护的资源，而不是整个结构体或函数。过度使用大粒度锁会增加资源竞争的可能性，从而提高死锁的风险。但过于细粒度的锁又会增加编程的复杂性，需要权衡。
  3. 使用defer确保解锁： 虽然这不能直接避免死锁，但它能确保在函数返回时锁被释放，避免因忘记解锁而导致的资源泄露或后续死锁。这是并发编程中的一个好习惯。
  4. 避免在持有锁时调用外部未知函数： 外部函数可能试图获取相同的锁，或者引入新的锁，从而打破你的加锁顺序约定，引入难以预料的死锁。

深入剖析Go语言中Channel死锁的常见场景与预防措施

从互斥锁的经典案例跳出来，我们再看看Go语言里更具特色的Channel。它虽然是并发利器，但用不好同样是死锁的温床。Channel的死锁通常发生在发送方和接收方互相等待，或者Channel容量不足以应对发送/接收速度时。

常见场景：

  1. 无缓冲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...”之后，程序就卡住了。

  2. Channel链式死锁： 多个goroutine通过Channel形成一个环形依赖。例如，goroutine A等待从Channel CA接收数据，而Channel CA的数据由goroutine B发送；goroutine B等待从Channel CB接收数据，而Channel CB的数据由goroutine A发送。这又是一个经典的循环等待。

  3. select语句的死锁： 当一个select语句中的所有case都无法执行（例如，所有Channel都阻塞），并且没有default分支时，select语句会永久阻塞，如果所有goroutine都因此阻塞，就会导致死锁。

预防措施：

  1. 使用带缓冲的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.")
}

    这个例子中，由于有了缓冲，发送者可以成功发送数据，程序不会死锁。

  2. 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分支，而不是死锁。

  3. 正确关闭Channel： 关闭Channel是一个信号，表示不会再有数据发送。接收方可以通过v, ok := <-ch来判断Channel是否关闭。不正确地关闭或不关闭Channel可能导致接收方永久等待。通常，发送方负责关闭Channel，并且只关闭一次。

  4. 避免循环依赖： 设计系统时，尽量避免goroutine之间形成环形的Channel依赖。如果必须存在，确保有明确的退出机制或超时机制来打破循环。

除了互斥锁和Channel，Golang并发中还有哪些隐蔽的死锁陷阱？

除了互斥锁和Channel，Go并发编程中还有一些不那么显眼，但同样能导致死锁的陷阱，这些往往与sync包的其他同步原语或不当的程序逻辑有关。

  1. 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()。

  2. 资源获取顺序不一致导致的复杂死锁： 这与互斥锁的AB-BA模式类似，但在更复杂的系统中，可能涉及多种资源（数据库连接、文件句柄、网络套接字等），而不仅仅是Go的同步原语。当多个goroutine需要获取多种不同类型的资源时，如果它们获取这些资源的顺序不一致，就可能形成循环等待。这其实是“哲学家就餐问题”的Go语言变体。

    避免策略： 强制执行全局的资源获取顺序。这通常需要精心设计，并在代码审查中严格把控。

  3. 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以及对各种同步原语行为的精确把握。调试死锁虽然麻烦，但往往也是学习并发编程最深刻的经历之一。

到这里，我们也就讲完了《Golang并发死锁原因与解决方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于并发编程,死锁的知识点！

并发编程 死锁
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>