Golang锁机制之sync.WaitGroup

​近日在复习golang的锁机制时看到一个案例，发现原作者给的答案不准确，这也是一些人容易踩到的坑，这里把分析过程写一下作为备忘。

原文链接：Golang字节跳动面试分享 - 知乎

原问题是：以下这段代码有什么问题，如何解决？

total := 0
for i := 1; i <= 10; i++ {
    sum += i
    go func() {
        total += i
    }()
}
fmt.Printf("total:%d sum %d", total, sum)

这段代码的问题至少有2个：

1. 子协程中直接使用了共享变量i，且没有锁控制；
2. 主协程没有等待所有子协程执行完成就打印了结果。

原作者给的答案是：

var lo sync.Mutex
func main() {
    total := 0
    for i := 1; i <= 10; i++ {
        nums += i
        lo.Lock()
        go func() {
            total += i
            lo.Unlock()
        }()
    }
    fmt.Printf("total:%d", total)
}

这个答案咋一看没有问题，但运行起来会发现输出的total=54，正确结果应该是55。

我们在子协程中打印一下i，会发现输出的i为2, 3, …, 10，所以输出的结果是54。
那么是否首个子协程（i=1）被阻塞了没有执行呢？其实不然。多运行几遍可能会发现，有时候会蹦出个i=11。或者我们直接在代码最后加一个睡眠 time.Sleep(1 * time.Second)，发现最后必然会输出i=11。

到这里问题的原因基本浮出水面了，当子协程执行total += i时，主协程已执行了i++进入了下一个循环，大概率在等待获取锁，所以才出现打印的i从2开始的现象。

我们将变量 i 作为函数入参传给子协程，再次运行，此时输出的 i 就是从1开始了，因为go语言中函数入参是值传递的，子协程内使用的 i 不再是共享变量。

func main() {
	total := 0
	sum := 0
	for i := 1; i <= 10; i++ {
		sum += i
		go func(i int) {
			total += i
			fmt.Printf("i:%d\n", i)
		}(i)
	}
	fmt.Printf("total:%d sum %d\n", total, sum)
}

此时虽然 i 的输出是正确了，但 total 大概率还是错误的，因为问题2还没有解决。
大家可以发现这段代码并没有加锁，实际也并不需要加mutex互斥锁。原作者加mutex锁的实际效果是让10个子协程是按1,2, … ,10的顺序执行的，并不能保证total值的正确。而每一个子协程都需要等待前一个子协程完成再去执行，这就失去了并发的意义，性能上还不如在主协程中串行执行。

所以这个问题实际应该使用sync.WaitGroup来解决，正确答案如下：

func main() {
	var wg sync.WaitGroup
	wg.Add(10)
	total := 0
	sum := 0
	for i := 1; i <= 10; i++ {
		sum += i
		go func(i int, done func()) {
			total += i
			done()
		}(i, wg.Done)
	}
	wg.Wait()
	fmt.Printf("total:%d sum %d\n", total, sum)
}