Go 实用技巧
Golang实用技巧
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 可能导致内存泄露的文章,可参考学习:
本文将在接下来技巧中深入探讨替代方案及其价值。
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