转自：https://mp.weixin.qq.com/s/HUqTC6i7aSUBVq0bsqfQXw
sync.WaitGroup() 用来做Goroutine的等待，当使用go启动多个并发程序，通过waitgroup可以等待所有go协程结束后再执行后面的代码逻辑
用途：阻塞协程的执行，直到所有的goroutine执行完成
WaitGroup总共有三个方法：Add(delta int),Done(),Wait()。简单的说一下这三个方法的作用。
Add：添加或者减少等待goroutine的数量
Done：相当于Add(-1)
Wait：执行阻塞，直到所有的WaitGroup数量变成0
WaitGroup主要维护了2个计数器，一个是请求计数器 v，一个是等待计数器 w，二者组成一个64bit的值，请求计数器占高32bit，等待计数器占低32bit。
那么等待计数器拿来干嘛？是因为同一个实例的Wait()方法支持多处调用，每一次Wait()方法执行，等待计数器 w 就会加1，而当请求计数器v为0触发Wait()时，要根据w的数量发送w份的信号量，正确的触发所有的Wait()，这虽然不是很常用的一个特性，但是在一些特殊场合是有用处的(比如多个并发都依赖于WaitGroup的实例的结束信号来进行下一个action)，演示代码如下
func main() {
wg := sync.WaitGroup{}
for i := 0; i < 10; i++ {
wg.Add(1)
go func() {
defer wg.Done()
}()
}
time.Sleep(2 * time.Second)
for j := 0; j < 3; j++ {
go func(i int) {
// 3个地方调用Wait()，通过等待j计时器，每个 Wait 都会被唤醒
wg.Wait()
fmt.Println("wait done now ", i)
}(j)
}
time.Sleep(10 * time.Second)
return
}
/*
输出如下，数字出现的顺序随机
wait done now 1
wait done now 0
wait done now 2
*/
同时，WaitGroup里还对使用逻辑进行了严格的检查，比如Wait()一旦开始不能再执行 Add() 操作
下面是带注释的源码，去掉了不影响代码逻辑的trace部分：
func (wg *WaitGroup) Add(delta int) {
statep := wg.state()
// 更新statep，statep将在wait和add中通过原子操作一起使用
state := atomic.AddUint64(statep, uint64(delta)<<32)
v := int32(state >> 32)
w := uint32(state)
if v < 0 {
panic("sync: negative WaitGroup counter")
}
if w != 0 && delta > 0 && v == int32(delta) {
// wait不等于0说明已经执行了Wait，此时不容许Add
panic("sync: WaitGroup misuse: Add called concurrently with Wait")
}
// 正常情况，Add会让v增加，Done会让v减少，如果没有全部Done掉，此处v总是会大于0的，直到v为0才往下走
// 而w代表是有多少个goruntine在等待done的信号，wait中通过compareAndSwap对这个w进行加1
if v > 0 || w == 0 {
return
}
// This goroutine has set counter to 0 when waiters > 0.
// Now there can't be concurrent mutations of state:
// - Adds must not happen concurrently with Wait,
// - Wait does not increment waiters if it sees counter == 0.
// Still do a cheap sanity check to detect WaitGroup misuse.
// 当v为0(Done掉了所有)或者w不为0(已经开始等待)才会到这里，但是在这个过程中又有一次Add，导致statep变化，panic
if *statep != state {
panic("sync: WaitGroup misuse: Add called concurrently with Wait")
}
// Reset waiters count to 0.
// 将statep清0，在Wait中通过这个值来保护信号量发出后还对这个Waitgroup进行操作
*statep = 0
// 将信号量发出，触发wait结束
for ; w != 0; w-- {
runtime_Semrelease(&wg.sema, false)
}
}
// Done decrements the WaitGroup counter by one.
func (wg *WaitGroup) Done() {
wg.Add(-1)
}
// Wait blocks until the WaitGroup counter is zero.
func (wg *WaitGroup) Wait() {
statep := wg.state()
for {
state := atomic.LoadUint64(statep)
v := int32(state >> 32)
w := uint32(state)
if v == 0 {
// Counter is 0, no need to wait.
if race.Enabled {
race.Enable()
race.Acquire(unsafe.Pointer(wg))
}
return
}
// Increment waiters count.
// 如果statep和state相等，则增加等待计数，同时进入if等待信号量
// 此处做CAS，主要是防止多个goroutine里进行Wait()操作，每有一个goroutine进行了wait，等待计数就加1
// 如果这里不相等，说明statep，在 从读出来 到 CAS比较 的这个时间区间内，被别的goroutine改写了，那么不进入if，回去再读一次，这样写避免用锁，更高效些
if atomic.CompareAndSwapUint64(statep, state, state+1) {
if race.Enabled && w == 0 {
// Wait must be synchronized with the first Add.
// Need to model this is as a write to race with the read in Add.
// As a consequence, can do the write only for the first waiter,
// otherwise concurrent Waits will race with each other.
race.Write(unsafe.Pointer(&wg.sema))
}
// 等待信号量
runtime_Semacquire(&wg.sema)
// 信号量来了，代表所有Add都已经Done
if *statep != 0 {
// 走到这里，说明在所有Add都已经Done后，触发信号量后，又被执行了Add
panic("sync: WaitGroup is reused before previous Wait has returned")
}
return
}
}
}
示例
package main
import (
"fmt"
"sync"
"time"
)
func main() {
var wg sync.WaitGroup
for i := 0; i < 5; i = i + 1 {
wg.Add(1)
go func(n int) {
defer wg.Done()
//defer wg.Add(-1)
EchoNumber(n)
}(i)
}
wg.Wait()
}
func EchoNumber(i int) {
time.Sleep(5000)
fmt.Println(i)
}
执行结果：
4 3 0 1 2
因为哪个协程先被cpu调度是不确定的，所以每次的执行结果也可能是不同的
这个程序如果不用WaitGroup，那么将看不见输出结果。因为goroutine还没执行完，主线程已经执行完毕。之前执行脚本，都是使用time.Sleep，用一个估计的时间等到子线程执行完，实在太low了
注释的defer wg.Add(-1)和defer wg.Done()作用一样
虽然channel也能实现，但是如果涉及不到协程之间的数据同步，这个感觉不错