与 Channels 相比，sync.WaitGroup 的优势是什么？

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《与 Channels 相比，sync.WaitGroup 的优势是什么？》，聊聊golang，我们一起来看看吧！

问题内容

我正在开发一个并发 Go 库，我偶然发现了 goroutine 之间的两种不同的同步模式，它们的结果相似：

等待组

package main

import (
    "fmt"
    "sync"
    "time"
)

var wg sync.WaitGroup

func main() {
    words := []string{"foo", "bar", "baz"}

    for _, word := range words {
        wg.Add(1)
        go func(word string) {
            time.Sleep(1 * time.Second)
            defer wg.Done()
            fmt.Println(word)
        }(word)
    }
    // do concurrent things here

    // blocks/waits for waitgroup
    wg.Wait()
}

渠道

package main

import (
    "fmt"
    "time"
)

func main() {
    words := []string{"foo", "bar", "baz"}
    done := make(chan bool)
    // defer close(done)
    for _, word := range words {
        // fmt.Println(len(done), cap(done))
        go func(word string) {
            time.Sleep(1 * time.Second)
            fmt.Println(word)
            done 
我被告知它sync.WaitGroup的性能略高一些，而且我已经看到它被普遍使用。但是，我发现频道更惯用。使用通道的真正优势是sync.WaitGroup什么和/或更好的情况可能是什么？

    正确答案

独立于您的第二个示例的正确性（如评论中所述，您没有按照您的想法做，但它很容易修复），我倾向于认为第一个示例更容易掌握。
现在，我什至不会说频道更惯用。通道是 Go 语言的一个标志性功能，并不意味着尽可能地使用它们是惯用的。Go
中的惯用语是使用最简单和最容易理解的解决方案：在这里，WaitGroup传达含义（您的主要功能是Wait让工人完成）和机械师（工人在他们完成时通知Done）。
除非您处于非常特殊的情况，否则我不建议在此处使用渠道解决方案。
理论要掌握，实操不能落！以上关于《与 Channels 相比，sync.WaitGroup 的优势是什么？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！