WaitGroup.Wait() 和内存屏障

在访问共享变量的多线程环境中，强制同步至关重要以防止出现意外结果。 Go 中的一种此类机制是“sync.WaitGroup”包，它有助于管理并发运行的 goroutine。

当前的问题围绕“WaitGroup.Wait()”和内存屏障之间的关系展开具体代码片段。在此代码片段中，启动多个 goroutine 来检查一组项目的特定条件。当所有 goroutine 完成后，调用“WaitGroup.Wait()”函数来阻塞调用 goroutine，直到等待计数达到零。

问题出现了：检查共享变量的条件是否安全“WaitGroup.Wait()”返回后的“条件”？

内存屏障剖析

内存屏障是一条硬件指令，它强制执行内存访问的特定顺序不同的线程。它确保屏障之前执行的内存写入的效果对于屏障之后执行的后续内存读取可见。

在 Go 语言中，内存屏障不会显式暴露给程序员。相反，像“WaitGroup”和“sync.Mutex”这样的同步基元会在必要时隐式强制执行内存屏障。

WaitGroup.Wait() 和 Happens-Before 关系

The “WaitGroup.Wait()”的文档指出，它会阻塞，直到等待计数达到零，而无需显式建立发生前关系。然而，内部实现细节表明“WaitGroup.Wait()”确实建立了发生前关系。这种关系意味着“WaitGroup.Wait()”之前执行的所有内存写入保证对“WaitGroup.Wait()”之后执行的内存读取可见。

条件检查的安全性

基于“WaitGroup.Wait()”建立的happens-before关系，在“WaitGroup.Wait()”返回后检查共享变量“condition”的条件是安全的。这一保证确保所有 goroutine 都已完成其执行，从而确保如果满足任何一项的条件，“条件”的值已被至少一个 goroutine 修改。

Race Condition Caveat

需要注意的是，只有当正在处理的项目数量大于 1 时，在“WaitGroup.Wait()”之后检查“条件”的安全性才成立。如果项目数为 1，则可能会发生竞争条件，即在调用“WaitGroup.Wait()”之前没有 goroutine 修改“条件”。因此，建议通过确保项目数始终大于 1 来避免这种情况。