理解并应用WaitGroups

从现在开始，努力学习吧！本文《理解并应用WaitGroups》主要讲解了等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

我想了解我关于 waitgroups 的逻辑是否正确，并查看是否有更有效的方法来构建我的代码。目标是尽快执行任务。

我的代码填充了一个 _urls 通道，该通道是通过标准输入填充的。然后我旋转两个 waitgroup，一个从 _urls 通道读取，另一个从 _downloads 通道读取，该通道由第一个 waitgroup 中的 goroutine 提供。

代码基本上如下所示：

// declare channels
    _urls := make(chan string)
    _downloads := make(chan string)

    // first waitgroup with 2 goroutines
    var wg sync.WaitGroup
    for i := 0; i < concurrency; i++ {

        wg.Add(2)

        go func() {
            defer wg.Done()
            for url := range _urls {
                // perform GET request and inspect the responseBody    
            }

        }()

        go func() {
            defer wg.Done()
            for url := range _urls {
                // perform a HEAD request to look for a certain file
                // if the file exists, send to the _downloads channel                
                _downloads <- url
            }
        }()
    }

    // second waitgroup with 1 goroutine
    var dwg sync.WaitGroup
    for i := 0; i < concurrency; i++ {

        dwg.Add(1)

        go func() {
            defer wg.Done()
            for url := range _downloads {
                // perform the download
            }
        }()
    }

我关心的是这是否是为 _downloads 频道提供数据的有效方式，或者仅在第一个 waitgroup 中执行下载是否更有意义。

解决方案

我使用工作池模式 https://gobyexample.com/worker-pools 做了类似的事情。如果您希望最大化并发性，这可能是正确的方向。

它使用 go 接口抽象作业，因此它可以是 HEAD、GET、Download 或任何其他将来有意义的东西。调度程序将作业发送到管理工作池并将结果发回的调度程序。

这里是 README 和代码的链接。

它使用等待组来跟踪活动工人的数量，而不是作业的数量。 Worker 执行 for {} Loop 并仅在从完成通道读取 true 时退出。在这种情况下，使用等待组是为了正常关闭。在您的示例中，许多工作人员可能正在执行长时间下载。因此，您的关闭逻辑可以在关闭之前等待 N 个作业离开。

这对于您的用例来说可能有点过分了。

终于介绍完啦！小伙伴们，这篇关于《理解并应用WaitGroups》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！