使用select在context.Context的Done通道上监听

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《使用select在context.Context的Done通道上监听》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

我不明白 context.context 中的 done() 通道如何按预期工作。模块文档（以及使用它的源代码）依赖于这种模式：

select {
case <-ctx.Done():
    return ctx.Err()

case results <- result:
}

如果context被取消或超时，done()返回的通道将关闭，err()变量保存原因。

我对这种方法有两个问题：

1. 通道关闭时 select 的行为是什么？案件何时以及为何立案？没有作业这一事实有相关性吗？

2. 根据语言参考：

   如果一个或多个通信可以继续进行，则通过统一的伪随机选择选择一个可以继续进行的通信。

   如果选择是随机的，那么当取消 context 时，该模式如何保证我不会沿着管道发送结果？我会理解是否按申报顺序评估案件（并选择封闭渠道案件）。

如果我完全偏离了轨道，请从更好的角度向我解释一下。

正确答案

本案例：

case <-ctx.done():

具有通讯功能：

<-ctx.done()

这是来自频道的接收。 Spec: Receive operator:

因此，当 ctx.done() 返回的通道关闭时，可以立即进行接收。这样控制流就可以进入这种情况了。

如果其他 case (results <- result) 在上下文取消时也可以继续，则（伪）随机选择一个，无法保证会是哪一个。

如果您不想在上下文已取消的情况下在 results 上发送值，请在 select 之前检查 ctx.done() 通道以及另一个非阻塞 select：

select {
case <-ctx.Done():
    return ctx.Err()
default:
}

select {
case <-ctx.Done():
    return ctx.Err()

case results <- result:
}

请注意，您必须将 default 分支添加到第一个选择，否则它将阻塞，直到上下文被取消。如果存在 default 分支并且上下文尚未取消，则选择 default 分支，因此控制流可以转到第二个 select。

查看相关问题：

Force priority of go select statement

How does select work when multiple channels are involved?

理论要掌握，实操不能落！以上关于《使用select在context.Context的Done通道上监听》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！