Go实用技巧

Golang实用技巧

• Golang实用技巧
  • Context
    • 1. 为了gorouines更可靠，避免实用context.Background()
    • 2. 不幸得是，context.Value 不是我们的朋友
    • 3. 使用context.WithoutCancel 保持 context 活跃

Context

1. 为了gorouines更可靠，避免实用context.Background()

在我们同时管理多个任务时，我们会实用goroutine，对吧？每个goroutine专用于特定的功能，比如发HTTP请求或者查询数据库。当这些任务需要暂停时，问题就出现了，这也是棘手的地方。因为我们不希望goroutines永久停止或阻塞，没有办法退出。

“为什么我们应该避免直接使用 context.Background() ？”

我们之所以避免直接使用 context.Background()，主要是因为它无法在出现问题时停止或取消执行。它是我们能用context的最简单形式，没有值（values） 、没有截止日期（截止日期）、没有取消信号（cancellation signals）。当执行卡住或要顺利结束时，这可能会成为一个问题。

为了解决这个问题，通常我们依靠两个策略：取消（cancel）和超时（timeout）:

context.WithTimeout(ctx, duration)
context.WithTimeoutCause(ctx, duration, errors.New("custom message"))

context.WithCancel(ctx)
context.WithCancelCause(ctx)

context.WithDeadline(ctx)
context.WithDeadlineCause(ctx, deadline, errors.New("custom message"))

有了这些工具，我们启动每个 goroutine 都带有明确的预期：“goroutine可以及时完成任务或者解释为什么不能及时完成，另外必要情况下可以取消任务。”

以下几点请记住：

• WithTimeout 其实就是换了个名字的 WithDeadline。
• 最近更新的 Go（版本 1.20 和 1.21）中添加的 XXXCause 函数提供了更好的错误报告。
• 如果 XXXCause 发生超时，它会提供更详细的错误消息：“context deadline exceeded: custom message.”

“channels怎么样？我不想在channel上永久等待。”

为了确保不会无限等待处理channels，更好的管理方法是使用 select 语句，它允许我们设置超时选项：

select{
  case result := <-ch：
    fmt.Println("Received result:", result)
  case <-time.After(5*time.Second):
    fmt.Println("Timed out")
}

不过需要注意：使用 time.After 可能会导致短期内存泄露。在某些情况下，使用time.Timer 或 time.Ticker 可能更有效，因为它们能让我们更好地控制时间。

译者补充：关于 time.After 可能导致内存泄露的文章，可参考学习：

1. [golang]golang time.After使用不当导致内存泄露问题分析 - luoming1224 - 博客园 (cnblogs.com)
2. Go坑：time.After可能导致的内存泄露问题分析 - 九卷 - 博客园 (cnblogs.com)

本文将在接下来技巧中深入探讨替代方案及其价值。

2. 不幸得是，context.Value 不是我们的朋友

context.Value 似乎是一个方便的工具，因为它可以在 context 中携带一些数据，然后在需要的地方取出这些数据。

这会让我们的函数签名简介明了，不是吗？典型的例子是这样的：

func A(ctx context.Context, transactionID string){
    payment := db.GetPayment(ctx, transactionID)
    ctx := context.WithValue(ctx, "payment", payment)
    
    B(ctx)
}

func B(ctx context.Context){
    ...
    
    C(ctx)
}

func C(ctx context.Context){
    payment, ok := ctx.Value("payment").(payment)
    ...
}

在这段代码中，函数 A 获取付款记录并将其添加到 context 中， 在 B 内调用的函数 C 检索此付款。这种方法避免直接通过函数 B 传递付款记录，该函数不需要了解付款。

此方法看起来不错，因为：

• 允许我们省略函数传递特定不使用的数据，就像 B 函数一样。
• 允许将必要的数据保存在 context 中。
• 避免函数签名中的额外参数。

为什么不在函数中 A 中直接调用函数 C 呢？通常情况下，C与B的逻辑结合得很深，可能依赖它的某些计算和参数。

那么问题出在哪里呢？问题就出在这里：

• 放弃了Go在编译过程中提供的类型检查安全性。
• 我们将数据放入黑匣子中并希望以后能再找到它，而一周之后可能就像盲人搜索一样。
• 由于隐士传递，付款数据似乎可有可无，但实际上非常重要。

从个人角度来看，使用 ctx.Value 的主要问题在于它如何隐藏数据。这就像把东西放在一个没有明确标签的保险箱里。当然，数据被保存起来了，但检索数据却成了一个猜谜游戏。

明确我们正在传递的消息通常会减少以后的麻烦。

“那么，什么时候适合使用 context.Value() ?”

最好限制它的使用范围，但 Go 文档建议在跨API和进程间传递请求范围的值时使用它。以下是一些很好的用途：

你可以考虑使用它来跟踪某些与请求相关的数据，例如：

• 跟踪请求的开始时间
• 记录访问者的IP地址
• 管理追踪和跨度IDs
• 识别正在访问的HTTP路由
• …

上面例子中 ‘payment’ 支付数据与请求无关吗？

如果 ‘payment’ 支付信息在多个函数中都很重要，那么在函数参数显示传递它会更清晰、安全，并且有助于任何阅读代码的人立即理解该函数直接与‘payment’支付数据交互。

一般来说，最好避免在 context 中嵌入关键业务数据，这种策略可以保持代码清晰度和可维护性。

3. 使用context.WithoutCancel 保持 context 活跃

当在Go中实用context时，非常简单的一件就是直接使用带有取消功能的context。如果取消父级context，所有子context也会被取消。

比如，下面这个简单的例子：

parentCtx, cancel := context.WithCancel(context.Background())
childCtx, _ := context.WithCancel(parentCtx)

go func(ctx context.Context){
    <-ctx.Done()
    fmt.Println("Child context done")
}(childCtx)

cancel()

此段代码中，一旦我们取消 parentCtx, childCtx 也会被取消。这通常是我们想要的，但有时我们可能需要一个子context能够继续运行，即使父级context被取消了。

在Go中处理HTTP请求时，我们会经常遇到一个场景：在处理主请求后启动goroutine处理任务，如果处理不仔细可能会导致错误：

func handleRequest(req *http.Request){
    ctx := req.Context()
    
    go hookAfterRequest(ctx)
}

在我们考虑处理HTTP请求时，即使客户端断开连接，我们仍然需要记录详细信息并收集指标，而不是取消运行。

未完待翻译，感兴趣可以先看原仓库英文版。喜欢给个鼓励 star ！
中文：Go实用技巧
英文：go-practical-tips