GO 语言sync.WaitGroup和sync.Once

sync.WaitGroup

sync.WaitGroup类型（以下简称WaitGroup类型）是开箱即用的，也是并发安全的。同时，与我们前面讨论的几个同步工具一样，它一旦被真正使用就不能被复制了。它比通道更加适合实现这种一对多的goroutine协作流程。
写起来代码更整洁直观。

func WaitTest02() {
    logger.Info("start")
    sign := make(chan struct{}, 2)
    go func() {
        logger.Info("go 1")
        sign <- struct{}{}
    }()
    go func() {
        logger.Info("go 2")
        sign <- struct{}{}
    }()
    <-sign
    <-sign
}

func WaitTest01() {
    logger.Info("start")
    var wg sync.WaitGroup
    wg.Add(2)
    go func() {
        logger.Info("go 1")
        wg.Done()
    }()
    go func() {
        logger.Info("go 2")
        wg.Done()
    }()
    wg.Wait()
    logger.Info("end")
}

WaitGroup类型拥有三个指针方法：Add、Done和Wait。你可以想象该类型中有一个计数器，它的默认值是0。我们可以通过调用该类型值的Add方法来增加，或者减少这个计数器的值。

一般情况下，我会用这个方法来记录需要等待的goroutine的数量。相对应的，这个类型的Done方法，用于对其所属值中计数器的值进行减一操作。我们可以在需要等待的goroutine中，通过defer语句调用它。

而此类型的Wait方法的功能是，阻塞当前的goroutine，直到其所属值中的计数器归零。如果在该方法被调用的时候，那个计数器的值就是0，那么它将不会做任何事情。

注意事项：

1.不要尝试将计数器设置成负数，如： Add(1-) 会panic
2.确保先掉Add()设置好计数器再调用Wait()，才能按照期望的预期完成你的操作。两个goroutine同时调用Add和Wait 可能会
3.WaitGroup值是可以被复用的，但需要保证其计数周期的完整性。计数器的值始于0又归为0，可视为一个计数周期。
4.再次强调按照顺序来调用，通常需要反复地实验，才能够让WaitGroup值的方法抛出panic.虽然这不是每次都发生，但是在长期运行的程序中，这种情况发生的概率还是不小的，我们必须要重视它们。

sync.Once

Once 是一个只执行一个动作的对象。

type Once struct {
    m    Mutex
    done uint32     // 初始值为0表示还未执行过，1表示已经执行过
}
 
// Once 的实现超级简单
// 用 互斥锁做线程安全控制
// 用uint32的done字段标识是否执行过
func (o *Once) Do(f func()) {
    // 每次一进来先读标识位 0 标识没有被执行过，1 标识已经被执行过
    if atomic.LoadUint32(&o.done) == 1 {
        return
    }
    // 施加互斥锁
    o.m.Lock()
    defer o.m.Unlock()
    // 如果之前未被执行过，则执行
    if o.done == 0 {
        // 先调用目标函数, 然后标识位更该去为 1
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}

如果你熟悉GoF设计模式中的单例模式的话，那么肯定能看出来，这个Do方法的实现方式，与那个单例模式有很多相似之处。它们都会先在临界区之外判断一次关键条件，若条件不满足则立即返回。这通常被称为“快路径”，或者叫做“快速失败路径”。

如果条件满足，那么到了临界区中还要再对关键条件进行一次判断，这主要是为了更加严谨。这两次条件判断常被统称为（跨临界区的）“双重检查”。由于进入临界区之前，肯定要锁定保护它的互斥锁m，显然会降低代码的执行速度，所以其中的第二次条件判断，以及后续的操作就被称为“慢路径”或者“常规路径”。

别看Do方法中的代码不多，但它却应用了一个很经典的编程范式
第一个特点,由于Do方法只会在参数函数执行结束之后把done字段的值变为1，因此，如果参数函数的执行需要很长时间或者根本就不会结束（比如执行一些守护任务），那么就有可能会导致相关goroutine的同时阻塞。
例如，有多个goroutine并发地调用了同一个Once值的Do方法，并且传入的函数都会一直执行而不结束。那么，这些goroutine就都会因调用了这个Do方法而阻塞。因为，除了那个抢先执行了参数函数的goroutine之外，其他的goroutine都会被阻塞在锁定该Once值的互斥锁m的那行代码上。

第二个特点,Do方法在参数函数执行结束后，对done字段的赋值用的是原子操作，并且，这一操作是被挂在defer语句中的。因此，不论参数函数的执行会以怎样的方式结束，done字段的值都会变为1。
也就是说，即使这个参数函数没有执行成功（比如引发了一个panic），我们也无法使用同一个Once值重新执行它了。所以，如果你需要为参数函数的执行设定重试机制，那么就要考虑Once值的适时替换问题。

在很多时候，我们需要依据Do方法的这两个特点来设计与之相关的流程，以避免不必要的程序阻塞和功能缺失。