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

Posted 2023-02-19

【中文标题】Go 上下文取消函数的最佳实践

【英文标题】：Best practices on go context cancelation functions

【发布时间】：2021-12-30 16:31:42

【问题描述】：

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

文章对 go 中的上下文取消函数进行了如下说明：

"如果你愿意，你可以传递取消函数，但是， 强烈不推荐。这可能导致取消的调用者不 意识到取消上下文可能对下游产生的影响。 可能有由此衍生的其他上下文可能导致 程序以意想不到的方式运行。简而言之，绝不通过 围绕取消功能。”

但是，如果我希望激活父 context.Done() 通道，将取消函数作为参数传递似乎是唯一的选择（参见下面的代码 sn-p）。比如下面代码sn-p中的代码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 包及其取消功能相关的最佳实践？

【参考方案1】：

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

您无需将取消函数传递给function2，您只需在您生成的gooutune 中调用它即可运行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()
    
  ()
  //...

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

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

---

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

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 仍然等待两者都完成。这两个操作都不需要担心管理这个问题。

【讨论】：

感谢您的回复。实际上，你是对的，这是一个过于简单的例子。我有一个函数初始化两个模块的情况：（1）建立一个 gRPC 连接和（2）建立一个 WebSocket 连接。我想知道是否可以使用 contextWithCancel 来检测一个连接是否断开以关闭另一个连接。让我知道对问题添加编辑是否有意义。

是的，我认为这将是添加到您的问题的好背景。我将编辑我的答案以尝试解决这种情况。