Golang使用WaitGroup管理多goroutine执行-Golang-PHP中文网

Golang使用WaitGroup管理多goroutine执行

P粉602998670

发布： 2025-09-14 12:15:01

原创

987人浏览过

WaitGroup通过Add、Done、Wait方法实现并发任务同步，确保所有goroutine完成后再继续主程序，相比time.Sleep更可靠，比直接使用channel更简洁高效。

golang使用waitgroup管理多goroutine执行

Golang中的

WaitGroup

登录后复制

，在我看来，它是处理并发任务同步的利器，尤其是当你需要确保所有后台任务都完成之后，主程序才能继续执行或退出时。它就像一个计数器，你启动了多少个并发任务，就给它加上多少，每个任务完成时就减去一个，直到计数归零，主程序就知道可以安全地前进了。

解决方案

要使用

WaitGroup

登录后复制

管理多goroutine执行，核心在于三个方法：

Add(delta int)

登录后复制

、

Done()

登录后复制

和

Wait()

登录后复制

。它的工作机制其实非常直观：

初始化：首先创建一个
```
sync.WaitGroup
```
登录后复制
实例。
计数增加：每当你准备启动一个新的goroutine时，调用
```
wg.Add(1)
```
登录后复制
来增加计数器。这一步至关重要，必须在
```
go
```
登录后复制
关键字之前完成，否则可能会出现竞态条件，导致
```
Wait()
```
登录后复制
过早返回。
任务完成：在每个goroutine内部，确保任务执行完毕后调用
```
wg.Done()
```
登录后复制
。这会将计数器减一。通常，我们会利用
```
defer wg.Done()
```
登录后复制
来保证无论goroutine是否发生panic，计数器都能被正确减去。
等待完成：在主goroutine中，调用
```
wg.Wait()
```
登录后复制
。这个方法会阻塞当前goroutine，直到
```
WaitGroup
```
登录后复制
的计数器归零。

这是一个典型的使用示例：

package main

import (
    "fmt"
    "sync"
    "time"
)

func worker(id int, wg *sync.WaitGroup) {
    defer wg.Done() // 确保无论如何，任务完成时计数器都会减一
    fmt.Printf("Worker %d starting...\n", id)
    time.Sleep(time.Duration(id) * time.Second) // 模拟耗时操作
    fmt.Printf("Worker %d finished.\n", id)
}

func main() {
    var wg sync.WaitGroup
    numWorkers := 3

    fmt.Println("Main: Starting workers...")
    for i := 1; i <= numWorkers; i++ {
        wg.Add(1) // 启动前增加计数
        go worker(i, &wg)
    }

    fmt.Println("Main: Waiting for workers to complete...")
    wg.Wait() // 阻塞直到所有worker完成
    fmt.Println("Main: All workers completed. Exiting.")
}

登录后复制

为什么直接使用time.Sleep()或channel不能有效管理并发任务？

在我刚接触Go并发编程的时候，也曾天真地尝试过

time.Sleep()

登录后复制

。你可能会想，我启动了几个goroutine，估摸着它们大概需要多久，然后主程序就

time.Sleep(那个估摸的时间)

登录后复制

。但很快就会发现，这种做法非常脆弱，简直是“碰运气”：

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

不确定性：并发任务的执行时间是不确定的，受CPU调度、I/O阻塞等多种因素影响。你设定的
```
Sleep
```
登录后复制
时间可能太短，导致部分任务还没完成主程序就退出了；也可能太长，白白浪费了等待时间。这根本不是一个可靠的同步机制。
资源浪费：如果你的
```
Sleep
```
登录后复制
时间过长，那么主goroutine就会长时间空闲，白白占用系统资源，降低程序效率。
无法处理错误：如果某个goroutine因为错误提前退出，或者执行时间远超预期，
```
time.Sleep()
```
登录后复制
对此一无所知，也无法做出任何响应。

至于

channel

登录后复制

，它确实是Go并发编程的核心原语，功能强大，可以用于通信和协调。但对于“等待所有任务完成”这种特定场景，直接用

channel

登录后复制

来实现，反而会显得有些“杀鸡用牛刀”，代码会更复杂：

你可能需要为每个goroutine创建一个

chan struct{}

登录后复制

或者

chan bool

登录后复制

，然后每个goroutine完成时发送一个信号，主goroutine再循环接收这些信号。虽然可行，但相比

WaitGroup

登录后复制

的简洁明了，它引入了额外的通道管理开销和逻辑复杂度，特别是在任务数量不确定时，管理起来会比较繁琐。

WaitGroup

登录后复制

就是为了这种“计数等待”的场景而生的，它把这种模式抽象得非常优雅。

WaitGroup的Add()、Done()和Wait()方法各自扮演什么角色，以及它们的使用陷阱？

WaitGroup

登录后复制

的这三个方法，构成了其工作的核心循环。理解它们各自的职责和潜在的陷阱，是正确使用它的关键。

```
Add(delta int)
```
登录后复制
：这个方法用于增加
```
WaitGroup
```
登录后复制
的内部计数器。
```
delta
```
登录后复制
通常是正数，表示要等待的goroutine数量。

行者AI
行者AI绘图创作，唤醒新的灵感，创造更多可能

100

查看详情
- 角色：它告诉
```
WaitGroup
```
  登录后复制
  ，“嘿，我这里有
```
delta
```
  登录后复制
  个新的任务要启动了，你得等它们。”
- 陷阱：必须在启动goroutine之前调用
  Add()
  登录后复制
  。如果你在
```
go worker()
```
  登录后复制
  之后才调用
```
wg.Add(1)
```
  登录后复制
  ，那么主goroutine和
```
Add()
```
  登录后复制
  的调用之间就可能存在竞态条件。如果
```
worker
```
  登录后复制
  执行得非常快，甚至在
```
Add()
```
  登录后复制
  被调用之前就完成了并调用了
```
Done()
```
  登录后复制
  ，那么
```
WaitGroup
```
  登录后复制
  的计数器就可能永远不会达到正确的值，或者
```
Wait()
```
  登录后复制
  可能会过早地返回。一个常见的错误是把
```
wg.Add(1)
```
  登录后复制
  放在
```
go func() { ... }()
```
  登录后复制
  的匿名函数内部，这是错误的，因为匿名函数在另一个goroutine中执行，这又回到了竞态条件的问题。
```
Done()
```
登录后复制
：这个方法用于减少
```
WaitGroup
```
登录后复制
的内部计数器。它等同于
```
Add(-1)
```
登录后复制
。
- 角色：它告诉
```
WaitGroup
```
  登录后复制
  ，“我这个任务已经完成了，你可以把计数器减一了。”
- 陷阱：确保每个
  Add()
  登录后复制
  都有对应的
  Done()
  登录后复制
  被调用。如果某个goroutine没有调用
```
Done()
```
  登录后复制
  （比如因为panic没有被
```
defer
```
  登录后复制
  捕获，或者逻辑分支遗漏），那么
```
WaitGroup
```
  登录后复制
  的计数器将永远不会归零，导致
```
wg.Wait()
```
  登录后复制
  永远阻塞，造成死锁。因此，强烈建议使用
```
defer wg.Done()
```
  登录后复制
  来确保
```
Done()
```
  登录后复制
  总能被调用。另一个不常见的陷阱是，如果在
```
Done()
```
  登录后复制
  之后再次对同一个
```
WaitGroup
```
  登录后复制
  调用
```
Add()
```
  登录后复制
  ，可能会导致计数器为负数，这会引发panic。
```
Wait()
```
登录后复制
：这个方法会阻塞调用它的goroutine，直到
```
WaitGroup
```
登录后复制
的内部计数器归零。
- 角色：它是一个屏障，确保所有被
```
Add()
```
  登录后复制
  标记的任务都已通过
```
Done()
```
  登录后复制
  完成。
- 陷阱：Wait()
  登录后复制
  只能在计数器归零后解除阻塞。如果在计数器还没有归零时再次调用
```
Wait()
```
  登录后复制
  ，它会继续阻塞。另外，
```
Wait()
```
  登录后复制
  不应该在循环中重复调用，因为它会阻塞，直到所有任务完成，之后再次调用将立即返回。

在实际项目中，除了WaitGroup，还有哪些Go并发原语可以辅助管理复杂场景？

在实际的Go项目中，并发场景往往比简单的“等待所有任务完成”要复杂得多。这时，

WaitGroup

登录后复制

虽然好用，但它只是工具箱中的一个。我们还需要依赖其他Go并发原语来构建健壮、高效的并发系统。

```
context.Context
```
登录后复制
：这几乎是现代Go服务中处理并发任务取消、超时和传递请求范围值的标准方式。当我们需要在一个复杂的调用链中，从父goroutine向子goroutine传递取消信号，或者设置一个全局的请求超时时，
```
context
```
登录后复制
就显得不可或缺。比如，你启动了一个耗时的数据处理goroutine，但用户取消了请求，你就可以通过
```
context.WithCancel
```
登录后复制
创建的
```
context
```
登录后复制
来通知数据处理goroutine优雅地退出，而不是让它一直运行下去。
```
WaitGroup
```
登录后复制
只管等待，
```
context
```
登录后复制
则管协调和控制生命周期。
```
sync.Mutex
```
登录后复制
和
sync.RWMutex
登录后复制
：当多个goroutine需要访问和修改共享数据时，如果没有适当的同步机制，就会出现数据竞态，导致不可预测的结果。
- ```
sync.Mutex
```
  登录后复制
  （互斥锁）提供了一种独占访问共享资源的方式，任何时候只有一个goroutine可以持有锁并访问数据。
- ```
sync.RWMutex
```
  登录后复制
  （读写互斥锁）则更进一步，它允许多个goroutine同时读取数据（共享锁），但在写入时会独占（排他锁）。这在读多写少的场景下，能显著提升并发性能。我的经验是，只要涉及共享可变状态，锁几乎是必不可少的。
```
channel
```
登录后复制
：虽然前面提到
```
channel
```
登录后复制
不适合简单的等待所有任务完成，但它在goroutine之间的通信和编排（orchestration）方面是无与伦比的。
- 数据传递：goroutine之间安全地传递数据。
- 任务编排：控制任务的执行顺序，比如一个任务的输出作为另一个任务的输入。
- 信号通知：例如，一个goroutine完成某个阶段性工作后，通过
```
channel
```
  登录后复制
  通知另一个goroutine可以开始下一个阶段。
- 限流：使用带缓冲的
```
channel
```
  登录后复制
  可以实现工作池或并发限流，控制同时运行的goroutine数量，防止资源耗尽。