Golang sync包常用组件 互斥锁与等待组应用

Mutex解决数据竞态，确保共享资源的独占访问；WaitGroup用于等待一组协程完成，二者协同实现并发控制。

在Go语言的并发世界里，

sync

Mutex

WaitGroup

Mutex

WaitGroup

解决方案

Go语言的

sync

Mutex

WaitGroup

互斥锁（

sync.Mutex

互斥锁的核心思想是“互斥”，即在任何给定时刻，只有一个协程能够持有锁，从而访问被保护的共享资源。当一个协程尝试获取已被其他协程持有的锁时，它会被阻塞，直到锁被释放。

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

• 基本用法：

  sync.Mutex

  提供了两个主要方法：

  Lock()

  和

  Unlock()

  。

  • Lock()

    ：获取锁。如果锁已被其他协程持有，当前协程会阻塞。

  • Unlock()

    ：释放锁。通常与

    defer

    关键字一起使用，确保锁在函数退出时被释放，即使发生错误。

• 应用场景： 保护共享变量、数据结构（如

  map

  、

  slice

  、计数器等）在并发读写时的完整性。例如，一个全局计数器，多个协程同时对其进行增减操作时，如果不加锁，最终结果可能会不准确，出现“数据竞态”（data race）。

• 代码示例：

  package main
  
  import (
      "fmt"
      "sync"
      "time"
  )
  
  var (
      counter int
      mu      sync.Mutex // 声明一个互斥锁
  )
  
  func increment() {
      mu.Lock() // 获取锁
      defer mu.Unlock() // 确保锁在函数退出时被释放
      counter++
      fmt.Printf("Incremented counter to %d\n", counter)
  }
  
  func main() {
      fmt.Println("Mutex Example:")
      for i := 0; i < 5; i++ {
          go increment()
      }
      time.Sleep(time.Millisecond * 100) // 等待goroutine完成
      fmt.Printf("Final counter value: %d\n", counter)
  }

等待组（

sync.WaitGroup

等待组用于等待一组协程的完成。它提供了一种简单而有效的方式来同步主协程和它启动的子协程。

• 基本用法：

  sync.WaitGroup

  提供了三个主要方法：

  Add()

  、

  Done()

  和

  Wait()

  。

  • Add(delta int)

    ：将等待组的计数器增加

    delta

    。通常在启动新的协程之前调用，增加需要等待的协程数量。

  • Done()

    ：将等待组的计数器减1。通常在每个协程完成其工作时调用。

  • Wait()

    ：阻塞当前协程，直到等待组的计数器变为0。

• 应用场景： 当主协程需要启动多个子协程并行执行任务，并且需要在所有子协程都完成后才能继续执行后续逻辑时。例如，一个批处理系统，需要等待所有文件处理协程都完成后再生成报告。

• 代码示例：

  package main
  
  import (
      "fmt"
      "sync"
      "time"
  )
  
  func worker(id int, wg *sync.WaitGroup) {
      defer wg.Done() // 协程完成时调用Done()
      fmt.Printf("Worker %d starting...\n", id)
      time.Sleep(time.Millisecond * 50) // 模拟工作
      fmt.Printf("Worker %d finished.\n", id)
  }
  
  func main() {
      fmt.Println("\nWaitGroup Example:")
      var wg sync.WaitGroup // 声明一个等待组
  
      for i := 1; i <= 3; i++ {
          wg.Add(1) // 每次启动一个协程，计数器加1
          go worker(i, &wg)
      }
  
      wg.Wait() // 阻塞直到所有协程完成
      fmt.Println("All workers finished. Main goroutine continues.")
  }

sync.Mutex

在并发编程中到底解决了什么痛点？

在并发编程中，

sync.Mutex

举个例子，假设账户余额是100元。

1. 协程A读取余额100。
2. 协程B读取余额100。
3. 协程A将余额加10（期望110），并写入。
4. 协程B将余额加20（期望120），并写入。

最终余额可能是110或120，而不是期望的130。这就是数据竞态，多个协程在没有同步的情况下，同时访问并修改共享数据，导致程序行为不可预测，结果错误。这种错误很难复现，因为它们依赖于协程的调度时机，调试起来简直是噩梦。

sync.Mutex

可以说，

Mutex

什么时候该用

sync.WaitGroup

，它和通道（Channel）有什么不同？

sync.WaitGroup

WaitGroup

MyMap AI

使用AI将想法转化为图表

下载

那么，它和通道（Channel）有什么不同呢？这是一个非常好的问题，因为两者都涉及协程间的同步，但它们的侧重点和使用场景有显著区别：

1. 目的不同：

   • WaitGroup

     ：它的核心目的是等待完成。它只关心一个计数器，当计数器归零时，表示所有被等待的任务都完成了。它不用于数据传输。

   • Channel

     ：它的核心目的是通信和同步。它是一个协程间传递数据的管道，通过发送和接收操作自然地实现同步。它不仅能让协程等待，还能传递值，甚至可以用来传递信号（例如，一个空结构体

     struct{}

     的通道可以作为完成信号）。

2. 数据传输能力：

   • WaitGroup

     ：不具备数据传输能力。它仅仅是一个计数器。

   • Channel

     ：具备数据传输能力。你可以通过通道发送任何类型的数据。

3. 使用模式：

   • WaitGroup

     ：通常是一对多的模式。一个主协程等待多个子协程。主协程

     Add

     ，子协程

     Done

     ，主协程

     Wait

     。

   • Channel

     ：可以是一对一、一对多、多对一、多对多的通信模式。它的灵活性更高，可以构建更复杂的并发模型，比如工作池、生产者-消费者模式等。

4. 复杂性与开销：

   • WaitGroup

     ：相对简单，开销较小。它只是一个简单的计数器操作。

   • Channel

     ：内部实现相对复杂，涉及队列、锁等，开销会略大一些，但通常在可接受范围内。

总结来说： 当你只是想知道“所有这些任务都搞定了没？”而不需要从这些任务中收集数据或进行复杂通信时，

WaitGroup

Channel

WaitGroup

Channel

互斥锁与等待组的常见陷阱及优化思考

尽管

Mutex

WaitGroup

sync.Mutex

1. 死锁（Deadlock）： 这是最常见的陷阱。

   • 忘记

     Unlock()

     ： 最典型的错误，

     Lock()

     后没有对应的

     Unlock()

     ，导致其他协程永远无法获取锁。解决方案：始终使用

     defer mu.Unlock()

     。
   • 重复加锁： 同一个协程对同一个

     Mutex

     连续调用两次

     Lock()

     ，第二次调用会阻塞自己，导致死锁。
   • 多锁顺序不一致： 当一个协程需要获取多个锁时，如果获取锁的顺序不一致，可能导致“AB-BA”死锁。例如，协程A先获取锁A再获取锁B，协程B先获取锁B再获取锁A。解决方案：约定所有协程都以相同的顺序获取锁。

2. 锁粒度过粗： 将大段代码用一个锁保护起来，导致并发度下降，性能变差。虽然保证了正确性，但牺牲了效率。

   • 优化思考： 尽量缩小锁的范围，只在真正需要保护共享资源的关键代码段加锁。考虑使用更细粒度的锁，或者将数据分解成多个独立的部分，分别加锁。

3. 锁粒度过细： 保护不足，仍然可能出现数据竞态。

   • 优化思考： 确保所有对共享资源的读写操作都在锁的保护之下。

sync.WaitGroup

1. Add()

   后于

   Wait()

   ： 如果在

   Wait()

   之后再调用

   Add()

   ，

   Wait()

   可能已经返回了，导致新添加的任务没有被等待，或者程序直接panic。
   • 正确做法：

     Add()

     必须在启动协程之前调用，并且在

     Wait()

     之前完成所有

     Add()

     操作。

2. Done()

   调用次数不匹配：

   • Done()

     调用次数少于

     Add()

     ：

     WaitGroup

     的计数器永远不会归零，

     Wait()

     会一直阻塞，导致程序死锁。

   • Done()

     调用次数多于

     Add()

     ：

     WaitGroup

     的计数器会变成负数，导致程序panic。
   • 正确做法： 确保每个

     Add(1)

     都有一个对应的

     defer wg.Done()

     。

3. Add()

   在协程内部调用： 如果

   Add()

   放在

   go func()

   内部，那么在协程真正启动并执行

   Add()

   之前，主协程可能已经执行了

   Wait()

   ，导致问题。
   • 正确做法：

     wg.Add(1)

     应该在

     go

     关键字之前执行。

通用优化思考：

1. sync.RWMutex

   ： 如果你的共享资源是读多写少的情况，使用读写互斥锁（

   sync.RWMutex

   ）会更高效。它允许多个协程同时读取数据，但在写入时仍然保持独占。

2. sync/atomic

   包： 对于简单的计数器、布尔值等操作，

   sync/atomic

   包提供了原子操作，这些操作通常比使用

   Mutex

   更高效，因为它们是无锁的（lock-free）。
3. Channel代替锁： 在某些情况下，通过Channel进行通信可以完全避免使用锁，遵循“不要通过共享内存来通信，而要通过通信来共享内存”的Go并发哲学。这通常能带来更清晰、更不容易出错的设计。
4. 上下文（

   context

   包）： 对于长时间运行的协程，考虑使用

   context.Context

   来传递取消信号或超时信息，以便优雅地终止协程，避免资源泄露或不必要的等待。
5. 性能分析： 当并发程序出现性能瓶颈时，不要盲目优化。使用Go的pprof工具进行性能分析，找出真正的瓶颈所在，可能是锁竞争，也可能是其他IO或CPU密集型操作。

理解这些陷阱并掌握优化技巧，能帮助你写出更健壮、更高效的Go并发程序。并发编程确实需要细心和经验，但Go提供的这些工具，无疑大大降低了门槛。