go - 理解 WaitGroups 的逻辑

Question

我想了解我围绕 WaitGroups 的逻辑是否正确，并看看是否有更有效的方式来构建我的代码。目的是尽可能快地执行任务。

我的代码填充了 _urls通过标准输入填充的 channel 。然后我启动了两个 WaitGroups，一个从这个 _urls 中读取。 channel ，另一个从 _downloads 读取 channel ，它是从第一个 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 的有效方式。 channel ，还是只在第一个 WaitGroup 中执行下载更有意义。

Answer 1

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

它使用 go 接口(interface)抽象作业，因此它可能是 HEAD、GET、Download 或任何其他在 future 发生的有意义的事情。调度程序将作业发送到管理工作池并将结果发回的调度程序。

这是 README 的链接和代码。

它使用 WaitGroup 来跟踪活跃 worker 的数量，而不是工作。 worker 执行 for {} loop并且仅在他们从完成的 channel 中读取 true 时退出。在这种情况下，使用 WaitGroup 是为了正常关闭。在您的示例中，许多工作人员可能正在进行长时间下载。因此，您的关闭逻辑可以等待 N 个作业在关闭之前留下。

对于您的用例来说，这可能是矫枉过正。