Go 上下文取消函数的最佳实践

Question

我一直在阅读一些关于使用 golang 的 context 包的文章。我最近在博客中看到以下文章：http://p.agnihotry.com/post/understanding_the_context_package_in_golang/

这篇文章对 go 中的上下文取消函数做了以下说明：

“如果您愿意，您可以传递取消函数，但是，强烈不建议这样做。这可能会导致取消的调用者没有意识到取消上下文可能对下游产生什么影响。可能还会派生出其他上下文这可能会导致程序以意想不到的方式运行。简而言之，永远不要传递取消函数。”

但是，如果我希望激活父 context.Done() 通道，将取消函数作为参数传递似乎是唯一的选择（请参阅下面的代码片段）。例如，下面代码片段中的代码 Done 通道仅在执行 function2 时激活。

package main

import (
    "context"
    "fmt"
    "time"
)

func function1(ctx context.Context) {
    _, cancelFunction := context.WithCancel(ctx)
    fmt.Println("cancel called from function1")
    cancelFunction()
}

func function2(ctx context.Context, cancelFunction context.CancelFunc) {
    fmt.Println("cancel called from function2")
    cancelFunction()
}

func main() {
    //Make a background context
    ctx := context.Background()
    //Derive a context with cancel
    ctxWithCancel, cancelFunction := context.WithCancel(ctx)

    go function1(ctxWithCancel)
    time.Sleep(5 * time.Second)

    go function2(ctxWithCancel, cancelFunction)

    time.Sleep(5 * time.Second)

    // Done signal is only received when function2 is called
    <-ctxWithCancel.Done()
    fmt.Println("Done")
}

那么，传递这个取消函数实际上是一个问题吗？是否有与使用 context 包及其取消功能相关的最佳实践？

Answer 1

在您的具体示例中，代码量足够小，理解它的工作原理可能没有问题。当你用更复杂的东西function1替换时，问题就开始了。function2您链接到的文章给出了为什么传递取消上下文可以做一些难以推理的事情的具体原因，但更一般的原则是您应该尝试将协调工作（取消、旋转 goroutine）从底层工作中分离出来尽可能多地完成（无论function1正在做什么）。function2这只会有助于更轻松地独立推理代码的子部分，并有助于使测试变得更容易。“ function2does <something>”比“does <something>”更容易理解function2，并且也与“协调一致function1”。

您无需将取消函数传递给function2，只需在您生成的 goroutune 中调用它即可运行function2：

func main() {
  //...
  go func() {
    function2(ctxWithCancel)
    cancelFunction()
  }()
  //...
}

这是侄女，因为确定何时取消的协调工作全部包含在调用函数中，而不是分散在多个函数中。

如果您想function2有条件地取消上下文，请让它显式返回某种值，指示是否发生了某些可取消的条件：

func function2(ctx context.Context) bool {
  //...
  if workShouldBecanceled() {
    return true
  }
  //...
  return false
}

func main() {
  //...
  go func() {
    if function2(ctxWithCancel) {
      cancelFunction()
    }
  }()
  //...
}

这里我使用了一个布尔值，但通常这种模式与 s 一起使用error- 如果function2返回一个非 nil error，则取消其余的工作。

根据您在做什么，类似的东西errgroup.WithContext可能对您有用。这可以协调多个并发操作，所有这些操作都可能失败，并在第一个操作失败后立即取消其他操作。

我尝试遵循上下文取消的另一个最佳实践：始终确保在某个时刻调用取消函数。从文档来看，调用取消函数两次是安全的，所以我经常这样做：

func main() {
  ctx, cancel := context.WithCancel(context.Background())
  defer cancel()
  //...
  if shouldCancel() {
    cancel()
  }
  //...
}

编辑回应评论：

如果您有多个长时间运行的操作（例如，服务器、连接等），并且您希望在第一个操作停止后立即关闭所有操作，那么上下文取消是一种合理的方法。但是，我仍然建议您在单个函数中处理所有上下文交互。像这样的事情会起作用：

func operation1(ctx context.Context) {
   for {
     select {
     case <-ctx.Done():
       return
     default:
     }
     //...
   }
}

func operation2(ctx context.Context) {
  // Similar code to operatoin1()
}

func main() {
  ctx, cancel := context.WithCancel(context.Background())
  var wg sync.WaitGroup
  wg.Add(2)
  go func() {
    defer wg.Done()
    defer cancel()
    operation1(ctx)
  }()
  go func() {
    defer wg.Done()
    defer cancel()
    operation2(ctx)
  }()
  wg.Wait()
}

一旦其中一个操作终止，另一个操作就会被取消，但main仍会等待两个操作完成。两个操作都不需要担心管理这个问题。