Go并发死锁问题及观察者模式应对方案

一分耕耘，一分收获！既然都打开这篇《Go并发死锁问题与观察者模式解决方法》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新Golang相关的内容，希望对大家都有所帮助！

本文针对 Go 语言并发编程中常见的死锁问题，以观察者模式的实现为例，深入剖析了死锁产生的原因，并提供了两种有效的解决方案：利用 quit 通道进行同步，以及使用 sync.WaitGroup 实现 goroutine 的等待。通过示例代码和详细解释，帮助读者理解并发编程中的同步机制，避免死锁的发生。

在 Go 语言的并发编程中，死锁是一个常见且棘手的问题。尤其是在使用 channel 进行 goroutine 间通信时，不正确的同步机制很容易导致死锁。以下将通过一个观察者模式的示例，分析死锁产生的原因，并提供两种解决方案。

问题分析

提供的代码尝试实现一个简单的观察者模式，其中 Publisher 负责发布消息，Subscriber 监听消息。代码中使用 channel 在 Publisher 和 Subscriber 之间传递消息。然而，这段代码存在死锁问题。

死锁的原因在于 Publisher 的 Pub 方法中，它向所有 listener 的 channel 发送消息，然后尝试向 quit channel 发送一个信号。同时，main 函数在调用 p.Pub 之后，立即尝试从 quit channel 接收信号。由于 quit channel 是 unbuffered channel，发送和接收必须同时发生。但是，发送操作发生在 main goroutine 中，而接收操作也在同一个 goroutine 中，导致 main goroutine 一直阻塞，等待一个永远不会发生的接收操作，从而引发死锁。

另外，如果移除 quit channel，程序虽然不会死锁，但 main goroutine 可能会在所有 subscriber 完成打印之前退出，导致只有部分 subscriber 接收到消息并打印。

解决方案一：使用 quit channel 进行同步

为了解决死锁问题，我们需要确保 main goroutine 在所有 subscriber 都完成消息处理后才退出。一种方法是在每个 subscriber 的 goroutine 中向 quit channel 发送一个信号，并在 main goroutine 中接收所有这些信号。

修改后的代码如下：

package main

import (
    "fmt"
)

type Publisher struct {
    listeners []chan int
}

type Subscriber struct {
    Channel chan int
    Name    string
}

func (p *Publisher) Sub(c chan int) {
    p.listeners = append(p.listeners, c)
}

func (p *Publisher) Pub(m int) {
    for _, c := range p.listeners {
        c <- m
    }
}

func (s *Subscriber) ListenOnChannel(quit chan int) {
    data := <-s.Channel
    fmt.Printf("Name: %v; Data: %v\n", s.Name, data)
    quit <- 0 // 发送完成信号
}

func main() {
    quit := make(chan int)
    p := &Publisher{}
    subscribers := []*Subscriber{&Subscriber{Channel: make(chan int), Name: "1"}, &Subscriber{Channel: make(chan int), Name: "2"}, &Subscriber{Channel: make(chan int), Name: "3"}}
    for _, v := range subscribers {
        p.Sub(v.Channel)
        go v.ListenOnChannel(quit) // 传递 quit channel
    }

    p.Pub(2)

    // 接收所有 subscriber 的完成信号
    for i := 0; i < len(subscribers); i++ {
        <-quit
    }
}

在这个解决方案中，每个 Subscriber 在完成消息处理后，都会向 quit channel 发送一个信号。main 函数接收到所有 subscriber 的信号后，才会退出。

解决方案二：使用 sync.WaitGroup 进行同步

另一种更优雅的解决方案是使用 sync.WaitGroup。WaitGroup 允许我们等待一组 goroutine 完成。

修改后的代码如下：

package main

import (
    "fmt"
    "sync"
)

type Publisher struct {
    listeners []chan int
}

type Subscriber struct {
    Channel chan int
    Name    string
}

func (p *Publisher) Sub(c chan int) {
    p.listeners = append(p.listeners, c)
}

func (p *Publisher) Pub(m int) {
    for _, c := range p.listeners {
        c <- m
    }
}

func (s *Subscriber) ListenOnChannel(wg *sync.WaitGroup) {
    defer wg.Done() // 在函数退出时调用 Done()
    data := <-s.Channel
    fmt.Printf("Name: %v; Data: %v\n", s.Name, data)
}

func main() {
    var wg sync.WaitGroup
    p := &Publisher{}
    subscribers := []*Subscriber{&Subscriber{Channel: make(chan int), Name: "1"}, &Subscriber{Channel: make(chan int), Name: "2"}, &Subscriber{Channel: make(chan int), Name: "3"}}
    for _, v := range subscribers {
        p.Sub(v.Channel)
        wg.Add(1) // 增加计数器
        go v.ListenOnChannel(&wg)
    }

    p.Pub(2)

    wg.Wait() // 等待所有 goroutine 完成
}

在这个解决方案中，我们首先创建了一个 sync.WaitGroup 实例。在启动每个 subscriber 的 goroutine 之前，我们调用 wg.Add(1) 来增加计数器。在每个 subscriber 的 ListenOnChannel 函数退出时，我们调用 wg.Done() 来减少计数器。最后，在 main 函数中，我们调用 wg.Wait() 来阻塞，直到计数器变为零，即所有 subscriber 都完成消息处理。

注意事项与总结

• 避免使用 buffered channel 掩盖问题：增加 channel 的 buffer size 可能会暂时解决死锁问题，但这只是掩盖了问题的本质。应该深入理解并发模型，找出真正的死锁原因。
• 选择合适的同步机制：quit channel 和 sync.WaitGroup 都可以用于 goroutine 的同步，选择哪种方式取决于具体场景。sync.WaitGroup 通常更简洁易用，尤其是在需要等待一组 goroutine 完成时。
• 理解并发编程模型：在进行并发编程时，需要深入理解 Go 语言的并发模型，包括 goroutine、channel 和 select 等概念。只有理解了这些概念，才能编写出安全可靠的并发程序。

通过以上示例和分析，我们可以更好地理解 Go 语言并发编程中的死锁问题，并掌握解决死锁的有效方法。在实际开发中，应该根据具体情况选择合适的同步机制，并时刻注意避免死锁的发生。

今天关于《Go并发死锁问题及观察者模式应对方案》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！