不要一劳永逸地使用 goroutine
约 815 字大约 3 分钟
2025-09-04
Goroutines 是轻量级的,但它们不是免费的: 至少,它们会为堆栈和 CPU 的调度消耗内存。 虽然这些成本对于 Goroutines 的使用来说很小,但当它们在没有受控生命周期的情况下大量生成时会导致严重的性能问题。 具有非托管生命周期的 Goroutines 也可能导致其他问题,例如防止未使用的对象被垃圾回收并保留不再使用的资源。
因此,不要在代码中泄漏 goroutine。 使用 go.uber.org/goleak 来测试可能产生 goroutine 的包内的 goroutine 泄漏。
一般来说,每个 goroutine:
- 必须有一个可预测的停止运行时间;或者
- 必须有一种方法可以向 goroutine 发出信号它应该停止
在这两种情况下,都必须有一种方式代码来阻塞并等待 goroutine 完成。
For example:
| Bad | Good |
|---|---|
| |
没有办法阻止这个 goroutine。这将一直运行到应用程序退出。 | 这个 goroutine 可以用 |
等待 goroutines 退出
给定一个由系统生成的 goroutine, 必须有一种方案能等待 goroutine 的退出。 有两种常用的方法可以做到这一点:
使用
sync.WaitGroup. 如果您要等待多个 goroutine,请执行此操作var wg sync.WaitGroup for i := 0; i < N; i++ { wg.Add(1) go func() { defer wg.Done() // ... }() } // To wait for all to finish: wg.Wait()添加另一个
chan struct{},goroutine 完成后会关闭它。 如果只有一个 goroutine,请执行此操作。done := make(chan struct{}) go func() { defer close(done) // ... }() // To wait for the goroutine to finish: <-done
不要在 init() 使用 goroutines
init() 函数不应该产生 goroutines。 另请参阅 避免使用 init()。
如果一个包需要一个后台 goroutine, 它必须公开一个负责管理 goroutine 生命周期的对象。 该对象必须提供一个方法(Close、Stop、Shutdown 等)来指示后台 goroutine 停止并等待它的退出。
| Bad | Good |
|---|---|
| |
当用户导出这个包时,无条件地生成一个后台 goroutine。 用户无法控制 goroutine 或停止它的方法。 | 仅当用户请求时才生成工作人员。 提供一种关闭工作器的方法,以便用户可以释放工作器使用的资源。 请注意,如果工作人员管理多个 goroutine,则应使用 |
更新日志
a059b-新增Uber的Go语言规范于
