在进入正文前，先对 及其相关背景知识做个简单的介绍，这里主要是 的基本使用，以及系统信号量的基础知识。对这些比较熟悉的小伙伴可以直接跳过这一节。
是 Golang 中最常见的并发控制技术之一，它的作用我们可以简单类比为其他语言中多线程并发控制中的 ，实例代码如下：
import (
“fmt”
“sync”
“time”
)
func main() {
fmt.Println(“Main starts…”)
var wg sync.WaitGroup
// 2 指的是下面有两个协程需要等待
wg.Add(2)
go waitFunc(&wg, 3)
go waitFunc(&wg, 1)
// 阻塞等待
wg.Wait()
fmt.Println(“Main ends…”)
}
func waitFunc(wg *sync.WaitGroup, num int) {
// 函数结束时告知 WaitGroup 自己已经结束
defer wg.Done()
time.Sleep(time.Duration(num) * time.Second)
fmt.Printf(“Hello World from %v\n”, num)
}
// 结果输出：
Main starts…
Hello World from 1
Hello World from 3
Main ends…
如果这里没有 ，主协程（main 函数）会直接跑到最后的 ，而没有中间两个 goroutine 的输出，加了 后，main 就会在 处阻塞等待两个协程都结束后才继续执行。
上面我们看到的 的三个方法：、 和 也是 对象仅有的三个方法。
信号量（Semaphore）是一种用于实现多进程或多线程之间同步和互斥的机制，也是 中所采用的技术。并且 自身的同步原理，也与信号量很相似。
由于翻译问题，不熟悉的小伙伴经常将信号量（Semaphore）和信号（Signal）搞混，这俩实际上是两个完全不同的东西。Semaphore 在英文中的本意是旗语，也就是航海领域的那个旗语，利用手旗或旗帜传递信号的沟通方式。在计算机领域，Semaphore，即信号量，在广义上也可以理解为一种进程、线程间的通信方式，但它的主要作用，正如前面所说，是用于实现进程、线程间的同步和互斥。
信号量本质上可以简单理解为一个整型数，主要包含两种操作：P（Proberen，测试）操作和 V（Verhogen，增加）操作。其中，P 操作会尝试获取一个信号量，如果信号量的值大于 0，则将信号量的值减 1 并继续执行；否则，当前进程或线程就会被阻塞，直到有其他进程或线程释放这个信号量为止。V 操作则是释放一个信号量，将信号量的值加 1。
可以把信号量看作是一种类似锁的东西，P 操作相当于获取锁，而 V 操作相当于释放锁。由于信号量是一种操作系统级别的机制，通常由内核提供支持，因此我们不用担心上述对信号量的操作本身会产生竞态条件，相信内核能搞定这种东西。
本文的重点不是信号量，因此不会过多展开关于信号量的技术细节，有兴趣的小伙伴可以查阅相关资料。
最后提一嘴技术之外的东西，Proberen 和 Verhogen 这俩单词眼生吧？因为它们是荷兰语，不是英语。为啥是荷兰语嘞？因为发明信号量的人，是上古计算机大神，来自荷兰的计算机先驱 Edsger W. Dijkstra 先生。嗯，对，就是那个 Dijkstra。
声明：本文所用源码均基于 Go 1.20.3 版本，不同版本 Go 的 源码可能略有不同，但设计思想基本是一致的。
相关源码非常短，加上注释和空行也只有 120 多行，它们全都在 中。
先来看 的定义，这里我把源文件中的注释都简单翻译了一下：
// 主 Goroutine 调用 Add 方法设置要等待的 Goroutine 数量，
// 然后每个 Goroutine 运行并在完成后调用 Done 方法。
// 同时，可以使用 Wait 方法阻塞，直到所有 Goroutine 完成。
//
// WaitGroup 在第一次使用后不能被复制。
//
// 根据 Go 内存模型的术语，Done 调用“同步于”任何它解除阻塞的 Wait 调用的返回。
type WaitGroup struct {
noCopy noCopy
state atomic.Uint64 // 高 32 位是计数器, 低 32 位是等待者数量（后文解释）。
sema uint32
}
类型是一个结构体，它有三个私有成员，我们一个一个来看。
1.1.1 noCopy
首先是 ，这个东西是为了告诉编译器， 结构体对象不可复制，即 是非法的。之所以禁止复制，是为了防止可能发生的死锁。但实际上如果我们对 对象进行复制后，至少在 1.20 版本下，Go 的编译器只是发出警告，没有阻止编译过程，我们依然可以编译成功。警告的内容如下：
为什么编译器没有编译失败，我猜应该是 Go 官方想尽量减少编译器对程序的干预，而更多地交给程序员自己去处理（此时 Rust 发出了一阵笑声）。总之，我们在使用 的过程中，不要去复制它就对了，不然非常容易产生死锁（其实结构体注释上也说了，WaitGroup 在第一次使用后不能被复制）。譬如我将文章开头代码中的 main 函数稍微改了改：
fmt.Println(“Main starts…”)
var wg sync.WaitGroup
// 2 指的是下面有两个协程需要等待
wg.Add(1)
wg2 :=wg
wg2.Add(1)
go waitFunc(&wg, 3)
go waitFunc(&wg2, 1)
// 阻塞等待
wg.Wait()
wg2.Wait()
fmt.Println(“Main ends…”)
}
// 输出结果
Main starts…
Hello World from 1
Hello World from 3
fatal error: all goroutines are asleep – deadlock!
goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc000042060?)
C:/Program Files/Go/src/runtime/sema.go:62 +0x27
sync.(*WaitGroup).Wait(0xe76b28?)
C:/Program Files/Go/src/sync/waitgroup.go:116 +0x4b
main.main()
D:/Codes/Golang/waitgroup/main.go:23 +0x139
exit status 2
为什么会这样？因为 wg 已经 了，这时我们复制了 wg 给 wg2，并且是个浅拷贝，意味着 wg2 内实际上已经是 后的状态了（state 成员保存的状态，即它的值），此时我们再执行 ，其实相当于执行了两次 。而后面 中对 wg2 只进行了一次 释放操作，main 函数在 时就陷入了无限等待，即 。等看了后面 和 的原理后，再回头来看这段死锁的代码，会更加清晰。
那么这段代码能既复制，又不死锁吗？当然可以，只需要把 提到 前面即可。
1.1.2 state atomic.Uint64
是 的核心，它是一个无符号的 64 位整型，并且用的是 包中的 ，所以 本身是线程安全的。至于 为什么能保证线程安全，因为它使用了 操作，而这个操作依赖于 CPU 提供的原子性指令，是 CPU 级的原子操作。
的高 32 位是计数器（counter），低 32 位是等待者数量（waiters）。其中计数器其实就是 数量的总和，譬如 后再 ，那么这个计数器就是 1 + 2=3；而等待数量就是现在有多少 goroutine 在执行 等待 被释放。
1.1.3 sema uint32
这玩意儿就是信号量，它的用法我们到后文结合代码再讲。
首先是 方法。 所有三个方法都没有返回值，并且只有 拥有参数，整个设计可谓简洁到了极点。
方法的第一句代码是：
if delta < 0 {
// Synchronize decrements with Wait.
race.ReleaseMerge(unsafe.Pointer(wg))
}
race.Disable()
defer race.Enable()
}
是判断当前程序是否开启了竞态条件检查，这个检查是在编译时需要我们手动指定的：，默认情况下并不开启，即 在默认情况下就是 。这段代码里如果程序开启了竞态条件检查，会将其关闭，最后再重新打开。其他有关 的细节本文不再讨论，这对我们理解 也没有太大影响，将其考虑进去反而会增加我们理解 核心机制的复杂度，因此后续代码中也会忽略所有与 相关的部分。
方法整理后的代码如下：
// 则所有在 Wait 上阻塞的 Goroutine 都会被释放。
// 如果计数器变为负数，则 Add 方法会 panic。
//
// 注意：当计数器为 0 时调用 delta 值为正数的 Add 方法必须在 Wait 方法之前执行。
// 而 delta 值为负数或者 delta 值为正数但计数器大于 0 时，则可以在任何时间点执行。
// 通常情况下，这意味着应该在创建 Goroutine 或其他等待事件的语句之前执行 Add 方法。
// 如果一个 WaitGroup 用于等待多组独立的事件，
// 那么必须在所有先前的 Wait 调用返回之后再进行新的 Add 调用。
// 详见 WaitGroup 示例代码。
func (wg *WaitGroup) Add(delta int) {
// 将 int32 的 delta 变成 unint64 后左移 32 位再与 state 累加。
// 相当于将 delta 与 state 的高 32 位累加。
state :=wg.state.Add(uint64(delta) << 32)
// 高 32 位，就是 counter，计数器
v :=int32(state >> 32)
// 低 32 位，就是 waiters，等待者数量
w :=uint32(state)
// 计数器为负数时直接 panic
if v < 0 {
panic(“sync: negative WaitGroup counter”)
}
// 当 Wait 和 Add 并发执行时，会有概率触发下面的 panic
if w !=0 && delta > 0 && v==int32(delta) {
panic(“sync: WaitGroup misuse: Add called concurrently with Wait”)
}
// 如果计数器大于 0，或者没有任何等待者，即没有任何 goroutine 在 Wait()，那么就直接返回
if v > 0 || w==0 {
return
}
// 当 waiters > 0 时，这个 Goroutine 将计数器设置为 0。
// 现在不可能有对状态的并发修改：
// – Add 方法不能与 Wait 方法同时执行，
// – Wait 不会在看到计数器为 0 时增加等待者。
// 仍然需要进行简单的健全性检查来检测 WaitGroup 的误用情况。
if wg.state.Load() !=state {
panic(“sync: WaitGroup misuse: Add called concurrently with Wait”)
}
// 重置 state 为 0
wg.state.Store(0)
// 唤醒所有等待者
for ; w !=0; w– {
// 使用信号量控制唤醒等待者
runtime_Semrelease(&wg.sema, false, 0)
}
}
这里我将原代码中的注释翻译成了中文，并且自己在每句代码前也都加了注释。
一开始，方法将参数 变成 uint64 后左移 32 位，和 相加。因为 的高 32 位是这个 的计数器，所以这里其实就是把计数器进行了累加操作：
接着，程序会分别取出已经累加后的计数器 ，和当前的等待者数量 ：
w :=uint32(state)
然后是几个判断：
if v < 0 {
panic(“sync: negative WaitGroup counter”)
}
// 当 Wait 和 Add 并发执行时，会有概率触发下面的 panic
if w !=0 && delta > 0 && v==int32(delta) {
panic(“sync: WaitGroup misuse: Add called concurrently with Wait”)
}
// 如果计数器大于 0，或者没有任何等待者，
// 即没有任何 goroutine 在 Wait()，那么就直接返回
if v > 0 || w==0 {
return
}
注释已经比较清晰了，这里主要展开解释一下第二个 ：。
意味着当前有 goroutine 在 ；
意味着 传入的是正整数，也就是正常调用；
意味着累加后的计数器等于传入的 ，这里最容易想到的符合这个等式的场景是：原计数器等于 0 时，也就是 wg 第一次使用，或前面的 已经全部结束时。
上述三个条件看上去有些冲突： 表示存在 ，而 按照分析应该不存在 。再往下分析，其实应该是 在获取的时候不存在 ，而 在获取的时候存在 。会有这种可能吗？会！就是并发的时候：当前 goroutine 获取了 ，然后另一个 goroutine 立刻进行了 ，接着本 goroutine 又获取了 ，过程如下：
我们可以用下面这段代码来复现这个 ：
var wg sync.WaitGroup
// 并发问题不易复现，所以循环多次
for i :=0; i < 100000; i++ {
go addDoneFunc(&wg)
go waitFunc(&wg)
}
wg.Wait()
}
func addDoneFunc(wg *sync.WaitGroup) {
wg.Add(1)
wg.Done()
}
func waitFunc(wg *sync.WaitGroup) {
wg.Wait()
}
// 输出结果
panic: sync: WaitGroup misuse: Add called concurrently with Wait
goroutine 71350 [running]:
sync.(*WaitGroup).Add(0x0?, 0xbf8aa5?)
C:/Program Files/Go/src/sync/waitgroup.go:65 +0xce
main.addDoneFunc(0xc1cf66?, 0x0?)
D:/Codes/Golang/waitgroup/main.go:19 +0x1e
created by main.main
D:/Codes/Golang/waitgroup/main.go:11 +0x8f
exit status 2
这段代码可能要多运行几次才会看到上述效果，因为这种并发操作在整个 的生命周期中会造成好几种 ，包括 方法中的。
因此，我们在使用 的时候应当注意一点：不要在被调用的 goroutine 内部使用 ，而应当在外面使用，也就是：
wg.Add(1)
go func(wg *sync.WaitGroup) {
defer wg.Done()
}(&wg)
wg.Wait()
// 错误
go func(wg *sync.WaitGroup) {
wg.Add(1)
defer wg.Done()
}(&wg)
wg.Wait()
从而避免并发导致的异常。
上面三个 都结束后，会再次对 的一致性进行判断，防止并发异常：
panic(“sync: WaitGroup misuse: Add called concurrently with Wait”)
}
这里 包括后面会出现的 都是 的原子操作。
根据前面代码的逻辑，当程序运行到这里时，计数器一定为 0，而等待者则可能 >=0，于是代码会执行一次 将 设为 0，接着执行通知等待者结束等待的操作：
for ; w !=0; w– {
runtime_Semrelease(&wg.sema, false, 0)
}
好了，这里又是让人迷惑的地方，我第一次看到这段代码时产生了下面几个疑问：
为什么 方法会有计数器为 0 的分支逻辑？计数器不是累加的吗？为什么要在 中通知等待者结束，不应该是 方法吗？那个 为什么需要循环 次？
一个一个来看。
为什么 方法会有计数器为 0 的分支逻辑？
首先，按照前面代码的逻辑，只有计数器 为 0 的时候，代码才会走到最后两句，而之所以为 0，是因为 的参数 是一个 ，也就是说， 可以为负数！那什么时候会传入负数进来呢？ 的时候。我们去看 的代码，会发现它非常简单：
func (wg *WaitGroup) Done() {
wg.Add(-1)
}
所以， 操作或是我们手动给 传入负数时，就会进入到 最后几行逻辑，而 本身也意味着当前 goroutine 的 结束，需要同步给外部的 让它不再阻塞。
为什么要在 中通知等待者结束，不应该是 方法吗？
嗯，这个问题其实在上一个问题已经一起解决了，因为 实际上调用了 。
那个 为什么需要循环 次？
这个函数按照字面意思，就是释放信号量。源码在 中，函数声明如下：
// 并在有等待 Semacquire 函数被阻塞的协程时通知它们继续执行。
// 它旨在作为同步库使用的简单唤醒基元，不应直接使用。
// 如果 handoff 参数为 true，则将 count 直接传递给第一个等待者。
// skipframes 参数表示在跟踪时要忽略的帧数，从 runtime_Semrelease 的调用者开始计数。
func runtime_Semrelease(s *uint32, handoff bool, skipframes int)
第一个参数就是信号量的值本身，释放时会 +1。
第二个参数 在我查阅了资料后，根据我的理解，应该是：当 为 时，仅正常唤醒其他等待的协程，但是不会立即调度被唤醒的协程；而当 为 时，会立刻调度被唤醒的协程。
第三个参数 ，看上去应当也和调度有关，但具体含义我不太确定，这里就不猜了（水平有限，见谅哈）。
按照信号量本身的机制，这里释放时会 +1，同理还存在一个信号量获取函数 会在信号量 > 0 时将信号量 -1，否则等待，它会在 中被调用。这也是 需要循环 次的原因：因为那 个 中会调用 并不断将信号量 -1，也就是减了 次，所以两个地方需要对冲一下嘛。
信号量和 的机制很像，但计数器又是反的，所以这里再多嘴补充几句：
信号量获取时（），其实就是在阻塞等待，P（Proberen，测试）操作，如果此时信号量 > 0，则获取成功，并将信号量 -1，否则继续等待；
信号量释放时（），会把信号量 +1，也就是 V（Verhogen，增加）操作。
方法我们在上面已经看到过了：
func (wg *WaitGroup) Done() {
wg.Add(-1)
}
同样的，这里我会把与 相关的代码都删掉：
func (wg *WaitGroup) Wait() {
for {
state :=wg.state.Load()
v :=int32(state >> 32) // 计数器
w :=uint32(state) // 等待者数量
if v==0 {
// 计数器为 0，直接返回。
return
}
// 增加等待者数量
if wg.state.CompareAndSwap(state, state+1) {
// 获取信号量
runtime_Semacquire(&wg.sema)
// 这里依然是为了防止并发问题
if wg.state.Load() !=0 {
panic(“sync: WaitGroup is reused before previous Wait has returned”)
}
return
}
}
}
比 简单多了，而且有了前面 的长篇大论为基础， 的代码看上去一目了然。
当计数器为 0，即没有任何 goroutine 调用 时，直接调用 ，没有任何意义，因此直接返回，也不操作信号量。
最后 也有一个防止并发问题的判断，而这个 panic 同样可以用前面 中的那段并发问题代码复现，大家可以试试。
中唯一不同的是，它用了一个无限循环 ，为什么？这是因为， 这个原子操作因为并发等原因有可能失败，此时就需要重新获取 ，把整个过程再走一遍。而一旦操作成功， 会在 处阻塞，直到 操作将计数器减为 0， 中释放了信号量。
至此， 的源码已全部解析完毕。作为 Golang 中最重要的并发组件之一， 的源码居然只有这么寥寥百行代码，倒是给我们理解它的原理降低了不少难度。
到此这篇关于Golang WaitGroup 底层原理及源码详解的文章就介绍到这了,更多相关Golang WaitGroup 原理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
