并发和重复请求，time.After() 是做什么用的？

学习知识要善于思考，思考，再思考！今天golang学习网小编就给大家带来《并发和重复请求，time.After() 是做什么用的？》，以下内容主要包含等知识点，如果你正在学习或准备学习Golang，就都不要错过本文啦~让我们一起来看看吧，能帮助到你就更好了！

我正在阅读《go 中的并发》，并且已经接近尾声了！总的来说，这是一本很棒的读物。在其中一个示例中，作者描述了如何模拟请求复制。代码示例如下：

func main() {
    doWork := func(
        done <-chan interface{},
        id int,
        wg *sync.WaitGroup,
        result chan<- int,
    ) {
        started := time.Now()
        defer wg.Done()

        // Simulate random load
        simulatedLoadTime := time.Duration(1*rand.Intn(5)) * time.Second

        /** use two separate select blocks because we want to send/receive two different values, the time.After (receive) and the id (send).
        / if they were in the same select block, then we could only use one value at a time, the other will get lost. */
        select {
        // do not want to return on <-done because we still want to log the time it took
        case <-done:
        case <-time.After(simulatedLoadTime):
        }

        select {
        case <-done:
        case result <- id:
        }

        took := time.Since(started)
        // Display how long handlers would have taken
        if took < simulatedLoadTime {
            took = simulatedLoadTime
        }
        fmt.Printf("%v took %v\n", id, took)
    }

    done := make(chan interface{})
    result := make(chan int)

    var wg sync.WaitGroup
    wg.Add(10)

    for i := 0; i < 10; i++ {
        go doWork(done, i, &wg, result)
    }

    firstReturned := <-result
    close(done)
    wg.Wait()

    fmt.Printf("Received an answer from #%v\n", firstReturned)
}

我不明白的一行是 case <-time.after(simulatedloadtime)。为什么会在这里？我们什么时候使用从该通道返回的值。该通道如何在选择块之外进行通信？无论出于何种原因，该行似乎在同步结果时间方面非常重要，因为如果我用 default: 替换它，结果将不同步。

解决方案

这已通过评论回答（请参阅 mkopriva's comment here），但让我提供一个“回答化”版本。

首先，一个小问题：

done := make(chan interface{})

我通常在这里看到 make(chan struct{}) 。由于从未发送任何实际值，因此通道的类型并不重要，但发送空的 struct 值根本不占用空间，而发送空的 interface{} 则占用空间。¹

现在，我们要在闭包中执行的操作² 是：

• 等待（或至少假装等待）某个服务器应答；
• 如果超时，则停止等待服务器；和
• 将我们的 id 传送到结果通道

或如果 done 频道已关闭（表明其他人比我们做得更好），则不必理会上述任何内容。

复杂的是，我们还将记录我们等待的时间，即使我们没有得到答案。

主协程：

• 创建 done 通道，其唯一目的是成为 closed，以便从它接收的数据立即在 eof 处返回其缺少值的零值；
• 衍生出一些数量（具体来说是 10 个）的工作 goroutine；
• 等待第一个提供结果（可能由于超时、结果而缺少结果）
• 关闭done通道以使剩余的worker终止；和
• 打印最终结果。

我们感兴趣的是为什么闭包的代码是用代码片段编写的：

    select {
    case <-done:
    case <-time.after(simulatedloadtime):
    }

在里面。

这里的技巧是 select 预先评估其所有替代方案。因此，它会评估 done 通道，但也会在开始选择过程之前调用 time.after()。然后，select 等待无论哪个有值或位于通道末尾并因此具有 eof（以先发生者为准）。

如果没有 goroutine 将结果发送回主 goroutine，则 done 通道将不会关闭。此时，所有 goroutines 将在 done 通道上阻塞。但所有 goroutine 也会调用 time.after。

time.after 代码启动一个 goroutine，在一段时间后，它将在通道上发送当前时间。然后它返回该通道。因此，这两个 <- 操作中至少有一个将完成：要么 done 通道将关闭，要么关闭，并且由于 eof，我们将在其上得到零值，或者time.after 返回的通道将发送一个时间，我们将收到该值。无论我们实际获得哪个值，我们都会将该值放在地板上，但事实上，两个 <- 运算符之一最终将解除阻塞，保证了该 goroutine 最终能够继续进行。

首先发生的事件将是 done 通道的关闭或时间的接收。我们不知道这是哪一个，因为我们不知道 done 通道需要多长时间才能关闭，但时间的上限是无论我们的持续时间有多长。传递给 time.after。也就是说，要么 done （最终）发生，要么在我们选择的时间之后， time.after 部分发生。其中之一肯定会发生。

现在，如果我们不关心记录我们花费的时间，我们可以将其写为：

select {
    case <-done:
        return
    case <-time.after(simulatedloadtime):
        // everything else happens here
    }

但请注意原始代码中的注释：

// do not want to return on <-done because we still want to log ...

这解释了为什么缺少 return。

由于超时，我们现在必须尝试将 id 发送到主 goroutine。然而，我们可能无法做到这一点：其他一些工作 goroutine 可能会比我们先于发送，而主 goroutine 仅从通道读取一个值。为了确保我们不会陷入困境，我们还有另一个 select。我们将尝试发送我们的 id，但如果 done 通道现在关闭或关闭，则停止。然后我们将记录并返回。

¹我一直认为 go 应该有一个预先声明的空结构类型，只是为了方便和风格。我们将在这里将其用于我们的 done 频道。我们也会将其用于仅作为集合而存在的地图，只不过它们也将具有预先声明的仅方便和样式的类型。但这完全是另一回事。

²这里没有特别好的理由使用闭包。未导出的普通函数也可以正常工作。鉴于我们正在使用闭包，我们可以捕获 done 通道、wg *waitgroup 值和 result 通道，而不是将它们作为参数。我不清楚为什么作者选择将它写成一个可以成为函数的闭包，然后不去理会闭包给我们带来的任何好处。

理论要掌握，实操不能落！以上关于《并发和重复请求，time.After() 是做什么用的？》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！