go select语句的强制优先级

Question

我有以下代码：

func sendRegularHeartbeats(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            return
        case <-time.After(1 * time.Second):
            sendHeartbeat()
        }
    }
}

这个函数在一个专门的 go-routine 中执行并且每秒发送一个心跳消息。当上下文被取消时，整个过程应该立即停止。

现在考虑以下场景：

ctx, cancel := context.WithCancel(context.Background())
cancel()
go sendRegularHeartbeats(ctx)

这会以封闭的上下文启动心跳例程。在这种情况下，我不希望传输任何心跳。所以应该立即输入select中的第一个case块。

但是，似乎无法保证评估 case 块的顺序，并且代码有时会发送心跳消息，即使上下文已经取消。

实现这种行为的正确方法是什么？

我可以在第二个 case 中添加一个“isContextclosed”检查，但这看起来更像是一个丑陋的解决方法。

Answer 1

如果保持操作的优先级绝对关键，您可以：

• 在单独的 goroutine 中从每个通道消费
• 让每个 goroutine 向共享的第三个通道写入一条消息，指明其类型
• 让第三个 goroutine 从该通道消费，读取它接收到的消息以确定它是一个滴答，应该sendHeartbeat，或者它是一个取消，它应该退出

这样，在其他通道上接收到的消息将（可能 - 你不能保证并发例程的执行顺序）按照它们被触发的顺序进入第三个通道，允许您可以适当地处理它们。

然而，值得注意的是，这可能不是必需的。 select 不能保证如果多个案例同时成功会执行哪个case。这可能是一个罕见的事件；在select 处理任何一个之前，cancel 和ticker 都必须触发。大多数情况下，在任何给定的循环迭代中，只有一个或另一个会触发，因此它的行为将完全符合预期。如果您可以容忍在取消后触发一个额外的心跳的罕见情况，那么您最好保留现有的代码，因为它更有效且更具可读性。

Answer 2

事先说明：

您的示例将按照您的预期工作，就好像在调用 sendRegularHeartbeats() 时上下文已经取消一样，case <-ctx.Done() 通信将是唯一准备好继续并因此被选中的通信。另一个case <-time.After(1 * time.Second) 只会在1 秒后 准备好继续，所以一开始不会被选中。但要在可能准备好多个案例时明确处理优先级，请继续阅读。

---

与switch statement 的case 分支不同（评估顺序是它们列出的顺序），select statement 的case 分支中没有优先级或任何顺序保证。

引用Spec: Select statements:

如果一个或多个通信可以继续，通过统一的伪随机选择选择一个可以继续的通信。否则，如果存在默认情况，则选择该情况。如果没有默认情况，“select”语句会阻塞，直到至少有一个通信可以继续。

如果可以进行更多通信，则随机选择一个。期间。

如果您想保持优先级，您必须自己（手动）执行此操作。您可以使用多个 select 语句（后续的，不是嵌套的）来执行此操作，在 earlier select 中列出具有更高优先级的语句，还请务必添加 default 分支以避免阻塞如果这些还没有准备好继续。您的示例需要 2 个 select 语句，第一个检查 <-ctx.Done() 因为这是您想要更高优先级的语句。

我还建议使用单个 time.Ticker 而不是在每次迭代中调用 time.After()（time.After() 在后台也使用 time.Ticker，但它不会重复使用它只是“扔掉它”并创建下次通话时换一个新的）。

这是一个示例实现：

func sendRegularHeartbeats(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()

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

        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            sendHeartbeat()
        }
    }
}

如果在调用sendRegularHeartbeats() 时上下文已经取消，这将不会发送任何心跳，因为您可以在Go Playground 上检查/验证它。

如果您将 cancel() 调用延迟 2.5 秒，则将发送恰好 2 个心跳：

ctx, cancel := context.WithCancel(context.Background())
go sendRegularHeartbeats(ctx)
time.Sleep(time.Millisecond * 2500)
cancel()
time.Sleep(time.Second * 2)

在Go Playground 上试试这个。

Answer 3

接受的答案有一个错误的建议：

func sendRegularHeartbeats(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()

    for {
        //first select 
        select {
        case <-ctx.Done():
            return
        default:
        }

        //second select
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            sendHeartbeat()
        }
    }
}

这无济于事，因为以下情况：

1. 两个频道都是空的
2. 首先选择运行
3. 两个通道同时收到一条消息
4. 你在同一个概率游戏中，就好像你在第一次选择中什么都没做一样

另一种但仍然不完美的方法是在使用代码事件后防止并发的 Done() 事件（“错误选择”），即

func sendRegularHeartbeats(ctx context.Context) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()

    for {            
        //select as usual
        select {
        case <-ctx.Done():
            return
        case <-ticker.C:
            //give priority to a possible concurrent Done() event non-blocking way
            select {
              case <-ctx.Done():
              return
            default:
            }
            sendHeartbeat()
        }
    }
}

警告：这个问题是它允许混淆“足够接近”的事件 - 例如即使一个ticker 事件更早到达，Done 事件也很快到来，抢占了心跳。目前还没有完美的解决方案。