文档【免费下载链接】uber_go_guide_cnUber Go 语言编码规范中文版. The Uber Go Style Guide .项目地址https://gitcode.com/gh_mirrors/ub/uber_go_guide_cn点击查看免费下载导读goroutine 是 Go 并发编程的基石但启动一个 goroutine 却不管它的退出是生产代码中常见且隐蔽的缺陷。本文基于 uber-go/guide 一节系统讲解等待 goroutine 退出的两种标准方案sync.WaitGroup与chan struct{}并延伸到不要一劳永逸地使用 goroutinegoroutine-forget.md与不要在init()中使用 goroutinesgoroutine-init.md两条配套规范。读完本文你将掌握可预测、可停止、可验证的 goroutine 生命周期管理完整实战方案并学会用go.uber.org/goleak检测泄漏。一、核心规范必须有等待 goroutine 退出的手段规范原文src/goroutine-exit.md开宗明义给定一个由系统产生的 goroutine必须有一种方案能等待该 goroutine 退出wait for the goroutine to exit。这不是可选的锦上添花而是一条强制约束。它之所以被写进 Uber 编码规范是因为只启动、不等待、不回收的 goroutine 会带来一系列真实问题。规范给出了两种主流方案各有明确的适用场景。1. 多个 goroutine使用sync.WaitGroup当你要等待的 goroutine 不止一个时使用sync.WaitGroup。这是原文档给出的完整示例var wg sync.WaitGroup for i : 0; i N; i { wg.Add(1) go func() { defer wg.Done() // ... }() } // 等待所有 goroutine 执行完毕 wg.Wait()要点拆解wg.Add(1)必须在go语句之前调用且最好在创建 goroutine 的循环体内完成避免计数先清零、后追加的竞态。defer wg.Done()放在 goroutine 函数体第一行确保无论中间发生什么分支提前 return、panic 恢复等计数器都会递减。wg.Wait()会阻塞当前 goroutine直到计数器归零。它天然支持等待多个 goroutine 全部结束的语义且可以安全地被多个等待方并发调用。2. 单个 goroutine使用chan struct{}如果只需要等待一个goroutine用chan struct{}更轻量、语义更直接。原文档的完整示例done : make(chan struct{}) go func() { defer close(done) // ... }() // 等待 goroutine 执行完毕 -done要点拆解chan struct{}不携带任何数据仅用于信号传递零内存开销之外没有额外语义负担。goroutine 在结束时通过defer close(done)关闭通道——注意是关闭close而不是发送值这是 Go 中完成信号的惯用法。等待方执行-done会一直阻塞直到通道被关闭关闭后的通道会立即返回零值因此即使 goroutine 已经退出-done也不会卡死。为什么不发送done - struct{}{}因为 close 语义天然是只发生一次、广播给所有等待者且defer close(done)能保证 goroutine 无论从哪个分支退出都会发出信号。选择依据很简单多个 goroutine 用WaitGroup单个 goroutine 用chan struct{}。二、为什么不能一劳永逸地启动 goroutine等待退出只是手段确保能退出才是目的。配套规范 不要一劳永逸地使用 goroutineDont fire-and-forget goroutines 解释了背后的成本逻辑goroutine 不是免费的至少要为它的栈分配内存并占用 CPU 参与调度。单个 goroutine 的初始栈只有若干 KB成本看似微不足道但在大量、无受控生命周期地启动时会积累成显著的性能问题。泄漏会阻碍 GC无法停止的 goroutine 会持续持有其捕获的变量与资源引用导致本可回收的对象无法被垃圾回收。资源被无谓占用文件句柄、网络连接、ticker 等资源会被永不退出的 goroutine 一直攥在手里。因此规范的结论是不要在代码中泄漏 goroutine。每个 goroutine 必须满足二选一有一个可预测的停止时间点或者存在一种向其发送停止信号的途径。并且无论哪种情况调用方都必须有办法阻塞并等待它真正结束。反例与正解用 stop/done 双通道管理生命周期下面这段坏味道代码没有任何停止途径会一直运行到进程退出go func() { for { flush() time.Sleep(delay) } }()正确的做法是同时引入停止信号通道与完成通知通道并配合select与time.Tickervar ( stop make(chan struct{}) // 告诉 goroutine 停止 done make(chan struct{}) // 告诉我们 goroutine 退出了 ) go func() { defer close(done) ticker : time.NewTicker(delay) defer ticker.Stop() for { select { case -ticker.C: flush() case -stop: return } } }() // 其它地方... close(stop) // 指示 goroutine 停止 -done // 并等待它退出这段代码体现了几处关键工程细节stop通道负责请求停止done通道负责确认退出两者职责分离。用time.NewTicker取代裸time.Sleep配合defer ticker.Stop()释放定时器资源。select让 goroutine 在定时触发与收到停止信号之间可响应地切换避免无法中断的忙等。停止流程是有序的先close(stop)发出信号再-done阻塞等待保证信号到达与确认退出的因果关系不被打破。三、不要在init()里启动 goroutine第三条配套规范 不要在init()中使用 goroutines 处理的是包初始化阶段这一特殊场景并与 避免使用init()一节互相呼应。init()函数不应启动 goroutine原因很直接init()在包被导入时无条件执行用户对是否启动后台工作没有选择权。在init()里启动的 goroutine不受用户控制、没有停止手段资源也无法回收。反例Badfunc init() { go doWork() } func doWork() { for { // ... } }正解Good把后台工作的生命周期封装成一个对象由调用方显式创建、显式关闭type Worker struct{ /* ... */ } func NewWorker(...) *Worker { w : Worker{ stop: make(chan struct{}), done: make(chan struct{}), // ... } go w.doWork() return w } func (w *Worker) doWork() { defer close(w.done) for { // ... case -w.stop: return } } // Shutdown 告诉 worker 停止 // 并等待它完成。 func (w *Worker) Shutdown() { close(w.stop) -w.done }这个Worker模式把前面两条规范串成了完整闭环显式启动只有用户调用NewWorker才启动 goroutine而不是包导入即启动可停止Shutdown()通过close(w.stop)发出停止信号可等待Shutdown()内-w.done阻塞等待 goroutine 真正退出后才返回保证调用方在方法返回时资源已彻底释放。规范还特别补充如果 worker 内部管理多个 goroutine应改用WaitGroup参见 等待 goroutines 退出。这与第一节的选型规则完全一致——多对一用WaitGroup一对一用chan struct{}。值得留意的是规范中doWork示例的select分支里case -w.stop前有// ...占位实战中通常写作for { select { case -w.stop: return default: // 执行具体工作 } }或与 ticker/任务队列配合保证 goroutine 在空闲时也能响应停止信号。核心原则不变循环体必须周期性检查停止信号。四、用 goleak 在测试中验证零泄漏规范在 goroutine-forget.md 中给出了一条可落地的工程化建议使用go.uber.org/goleak检测可能产生 goroutine 的包内是否存在泄漏。goleak是 Uber 开源的 goroutine 泄漏检测库典型用法是在测试的TestMain中全局安装检测func TestMain(m *testing.M) { goleak.VerifyTestMain(m) }它会在每个测试结束后对比 goroutine 快照若发现测试期间启动的 goroutine 没有正常退出测试即失败。这样等待退出就不再只靠代码审查而是变成了编译测试期的强制约束——凡是违反每个 goroutine 必须有停止途径、必须有等待手段的实现都会在 CI 中被直接暴露。说明go.uber.org/goleak是第三方模块使用前需通过go get go.uber.org/goleak引入依赖。其具体 API 以官方模块文档为准。五、综合实战模板可停止、可等待、可测试的后台任务把三条规范合并可以得到一个生产可用的后台任务骨架它同时满足有停止信号、有等待手段、不在 init 中启动、可被 goleak 验证package worker import sync type Worker struct { stop chan struct{} done chan struct{} } // New 显式启动后台任务用户不调用就不会产生 goroutine。 func New() *Worker { w : Worker{ stop: make(chan struct{}), done: make(chan struct{}), } go w.run() return w } // run 是唯一的 goroutine 入口结束时关闭 done。 func (w *Worker) run() { defer close(w.done) for { select { case -w.stop: return default: // 执行任务... } } } // Shutdown 发送停止信号并阻塞等待 goroutine 退出。 func (w *Worker) Shutdown() { close(w.stop) -w.done } // 若管理多个 goroutine改用 WaitGroup 版本 type MultiWorker struct { stop chan struct{} wg sync.WaitGroup } func (m *MultiWorker) spawn(n int) { for i : 0; i n; i { m.wg.Add(1) go func() { defer m.wg.Done() for { select { case -m.stop: return default: // 执行任务... } } }() } } func (m *MultiWorker) Shutdown() { close(m.stop) m.wg.Wait() }调用方的标准用法w : worker.New() defer w.Shutdown() // 确保退出路径上一定会回收 goroutine // 业务逻辑...六、规范要点速查场景推荐做法对应源码文档等待多个 goroutine 退出sync.WaitGroupAdd/Done/Waitgoroutine-exit.md等待单个 goroutine 退出chan struct{}defer close(done)-donegoroutine-exit.md防止泄漏每个 goroutine 必须有停止途径或可预测终止点且可被等待goroutine-forget.md周期任务可停止stop/done双通道 selecttime.Tickergoroutine-forget.md包级后台任务封装为对象提供Close/Stop/Shutdown方法多 goroutine 用WaitGroupgoroutine-init.md测试验证go.uber.org/goleak在TestMain中检测泄漏goroutine-forget.md这三份文档位于本仓库 src/goroutine-exit.md、src/goroutine-forget.md、src/goroutine-init.md其中 管理 goroutine 生命周期 的相关指导自 2022-10-18 起被纳入 README.md 的指南目录见 README.md 中不要一劳永逸地使用 goroutine一节及其子节。仓库根目录的 README.md 中还提供了与 避免使用init()的交叉引用init()本身应尽量避免使用详见 src/init.md这是理解为什么不能在 init 中启动 goroutine的更深层背景。一句话总结启动一个 goroutine 之前先回答两个问题——它什么时候停、我如何等到它停如果答不上来就不要启动它。赞分享文档【免费下载链接】uber_go_guide_cnUber Go 语言编码规范中文版. The Uber Go Style Guide .项目地址https://gitcode.com/gh_mirrors/ub/uber_go_guide_cn点击查看免费下载相关推荐Uber Go Style Guide 实战等待 Goroutine 退出的两种规范模式Uber Go Style Guide 实战等待 Goroutine 退出的两种规范模式 本篇技术指南围绕 Uber Go Style Guide 中 Wai文档教程代码质量LintUber Go 编码规范不要在 init() 中启动 goroutine用显式生命周期管理替代Uber Go 编码规范不要在 init 中启动 goroutine用显式生命周期管理替代 导读 本文讲解 Uber Go 语言编码规范中文版 uber文档不要 fire-and-forget 启动 goroutineUber Go 规范中的 goroutine 生命周期管理不要 fire and forget 启动 goroutineUber Go 规范中的 goroutine 生命周期管理 导读本文基于 Uber Go 语言文档上一篇Draw.io Mermaid插件安装与实战指南文本驱动图表一步到位下一篇免费在线AI分词计算器Tiktokenizer让Token成本一清二楚创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Uber Go 编码规范实战：如何正确等待 Goroutine 退出并管理其生命周期
文档【免费下载链接】uber_go_guide_cnUber Go 语言编码规范中文版. The Uber Go Style Guide .项目地址https://gitcode.com/gh_mirrors/ub/uber_go_guide_cn点击查看免费下载导读goroutine 是 Go 并发编程的基石但启动一个 goroutine 却不管它的退出是生产代码中常见且隐蔽的缺陷。本文基于 uber-go/guide 一节系统讲解等待 goroutine 退出的两种标准方案sync.WaitGroup与chan struct{}并延伸到不要一劳永逸地使用 goroutinegoroutine-forget.md与不要在init()中使用 goroutinesgoroutine-init.md两条配套规范。读完本文你将掌握可预测、可停止、可验证的 goroutine 生命周期管理完整实战方案并学会用go.uber.org/goleak检测泄漏。一、核心规范必须有等待 goroutine 退出的手段规范原文src/goroutine-exit.md开宗明义给定一个由系统产生的 goroutine必须有一种方案能等待该 goroutine 退出wait for the goroutine to exit。这不是可选的锦上添花而是一条强制约束。它之所以被写进 Uber 编码规范是因为只启动、不等待、不回收的 goroutine 会带来一系列真实问题。规范给出了两种主流方案各有明确的适用场景。1. 多个 goroutine使用sync.WaitGroup当你要等待的 goroutine 不止一个时使用sync.WaitGroup。这是原文档给出的完整示例var wg sync.WaitGroup for i : 0; i N; i { wg.Add(1) go func() { defer wg.Done() // ... }() } // 等待所有 goroutine 执行完毕 wg.Wait()要点拆解wg.Add(1)必须在go语句之前调用且最好在创建 goroutine 的循环体内完成避免计数先清零、后追加的竞态。defer wg.Done()放在 goroutine 函数体第一行确保无论中间发生什么分支提前 return、panic 恢复等计数器都会递减。wg.Wait()会阻塞当前 goroutine直到计数器归零。它天然支持等待多个 goroutine 全部结束的语义且可以安全地被多个等待方并发调用。2. 单个 goroutine使用chan struct{}如果只需要等待一个goroutine用chan struct{}更轻量、语义更直接。原文档的完整示例done : make(chan struct{}) go func() { defer close(done) // ... }() // 等待 goroutine 执行完毕 -done要点拆解chan struct{}不携带任何数据仅用于信号传递零内存开销之外没有额外语义负担。goroutine 在结束时通过defer close(done)关闭通道——注意是关闭close而不是发送值这是 Go 中完成信号的惯用法。等待方执行-done会一直阻塞直到通道被关闭关闭后的通道会立即返回零值因此即使 goroutine 已经退出-done也不会卡死。为什么不发送done - struct{}{}因为 close 语义天然是只发生一次、广播给所有等待者且defer close(done)能保证 goroutine 无论从哪个分支退出都会发出信号。选择依据很简单多个 goroutine 用WaitGroup单个 goroutine 用chan struct{}。二、为什么不能一劳永逸地启动 goroutine等待退出只是手段确保能退出才是目的。配套规范 不要一劳永逸地使用 goroutineDont fire-and-forget goroutines 解释了背后的成本逻辑goroutine 不是免费的至少要为它的栈分配内存并占用 CPU 参与调度。单个 goroutine 的初始栈只有若干 KB成本看似微不足道但在大量、无受控生命周期地启动时会积累成显著的性能问题。泄漏会阻碍 GC无法停止的 goroutine 会持续持有其捕获的变量与资源引用导致本可回收的对象无法被垃圾回收。资源被无谓占用文件句柄、网络连接、ticker 等资源会被永不退出的 goroutine 一直攥在手里。因此规范的结论是不要在代码中泄漏 goroutine。每个 goroutine 必须满足二选一有一个可预测的停止时间点或者存在一种向其发送停止信号的途径。并且无论哪种情况调用方都必须有办法阻塞并等待它真正结束。反例与正解用 stop/done 双通道管理生命周期下面这段坏味道代码没有任何停止途径会一直运行到进程退出go func() { for { flush() time.Sleep(delay) } }()正确的做法是同时引入停止信号通道与完成通知通道并配合select与time.Tickervar ( stop make(chan struct{}) // 告诉 goroutine 停止 done make(chan struct{}) // 告诉我们 goroutine 退出了 ) go func() { defer close(done) ticker : time.NewTicker(delay) defer ticker.Stop() for { select { case -ticker.C: flush() case -stop: return } } }() // 其它地方... close(stop) // 指示 goroutine 停止 -done // 并等待它退出这段代码体现了几处关键工程细节stop通道负责请求停止done通道负责确认退出两者职责分离。用time.NewTicker取代裸time.Sleep配合defer ticker.Stop()释放定时器资源。select让 goroutine 在定时触发与收到停止信号之间可响应地切换避免无法中断的忙等。停止流程是有序的先close(stop)发出信号再-done阻塞等待保证信号到达与确认退出的因果关系不被打破。三、不要在init()里启动 goroutine第三条配套规范 不要在init()中使用 goroutines 处理的是包初始化阶段这一特殊场景并与 避免使用init()一节互相呼应。init()函数不应启动 goroutine原因很直接init()在包被导入时无条件执行用户对是否启动后台工作没有选择权。在init()里启动的 goroutine不受用户控制、没有停止手段资源也无法回收。反例Badfunc init() { go doWork() } func doWork() { for { // ... } }正解Good把后台工作的生命周期封装成一个对象由调用方显式创建、显式关闭type Worker struct{ /* ... */ } func NewWorker(...) *Worker { w : Worker{ stop: make(chan struct{}), done: make(chan struct{}), // ... } go w.doWork() return w } func (w *Worker) doWork() { defer close(w.done) for { // ... case -w.stop: return } } // Shutdown 告诉 worker 停止 // 并等待它完成。 func (w *Worker) Shutdown() { close(w.stop) -w.done }这个Worker模式把前面两条规范串成了完整闭环显式启动只有用户调用NewWorker才启动 goroutine而不是包导入即启动可停止Shutdown()通过close(w.stop)发出停止信号可等待Shutdown()内-w.done阻塞等待 goroutine 真正退出后才返回保证调用方在方法返回时资源已彻底释放。规范还特别补充如果 worker 内部管理多个 goroutine应改用WaitGroup参见 等待 goroutines 退出。这与第一节的选型规则完全一致——多对一用WaitGroup一对一用chan struct{}。值得留意的是规范中doWork示例的select分支里case -w.stop前有// ...占位实战中通常写作for { select { case -w.stop: return default: // 执行具体工作 } }或与 ticker/任务队列配合保证 goroutine 在空闲时也能响应停止信号。核心原则不变循环体必须周期性检查停止信号。四、用 goleak 在测试中验证零泄漏规范在 goroutine-forget.md 中给出了一条可落地的工程化建议使用go.uber.org/goleak检测可能产生 goroutine 的包内是否存在泄漏。goleak是 Uber 开源的 goroutine 泄漏检测库典型用法是在测试的TestMain中全局安装检测func TestMain(m *testing.M) { goleak.VerifyTestMain(m) }它会在每个测试结束后对比 goroutine 快照若发现测试期间启动的 goroutine 没有正常退出测试即失败。这样等待退出就不再只靠代码审查而是变成了编译测试期的强制约束——凡是违反每个 goroutine 必须有停止途径、必须有等待手段的实现都会在 CI 中被直接暴露。说明go.uber.org/goleak是第三方模块使用前需通过go get go.uber.org/goleak引入依赖。其具体 API 以官方模块文档为准。五、综合实战模板可停止、可等待、可测试的后台任务把三条规范合并可以得到一个生产可用的后台任务骨架它同时满足有停止信号、有等待手段、不在 init 中启动、可被 goleak 验证package worker import sync type Worker struct { stop chan struct{} done chan struct{} } // New 显式启动后台任务用户不调用就不会产生 goroutine。 func New() *Worker { w : Worker{ stop: make(chan struct{}), done: make(chan struct{}), } go w.run() return w } // run 是唯一的 goroutine 入口结束时关闭 done。 func (w *Worker) run() { defer close(w.done) for { select { case -w.stop: return default: // 执行任务... } } } // Shutdown 发送停止信号并阻塞等待 goroutine 退出。 func (w *Worker) Shutdown() { close(w.stop) -w.done } // 若管理多个 goroutine改用 WaitGroup 版本 type MultiWorker struct { stop chan struct{} wg sync.WaitGroup } func (m *MultiWorker) spawn(n int) { for i : 0; i n; i { m.wg.Add(1) go func() { defer m.wg.Done() for { select { case -m.stop: return default: // 执行任务... } } }() } } func (m *MultiWorker) Shutdown() { close(m.stop) m.wg.Wait() }调用方的标准用法w : worker.New() defer w.Shutdown() // 确保退出路径上一定会回收 goroutine // 业务逻辑...六、规范要点速查场景推荐做法对应源码文档等待多个 goroutine 退出sync.WaitGroupAdd/Done/Waitgoroutine-exit.md等待单个 goroutine 退出chan struct{}defer close(done)-donegoroutine-exit.md防止泄漏每个 goroutine 必须有停止途径或可预测终止点且可被等待goroutine-forget.md周期任务可停止stop/done双通道 selecttime.Tickergoroutine-forget.md包级后台任务封装为对象提供Close/Stop/Shutdown方法多 goroutine 用WaitGroupgoroutine-init.md测试验证go.uber.org/goleak在TestMain中检测泄漏goroutine-forget.md这三份文档位于本仓库 src/goroutine-exit.md、src/goroutine-forget.md、src/goroutine-init.md其中 管理 goroutine 生命周期 的相关指导自 2022-10-18 起被纳入 README.md 的指南目录见 README.md 中不要一劳永逸地使用 goroutine一节及其子节。仓库根目录的 README.md 中还提供了与 避免使用init()的交叉引用init()本身应尽量避免使用详见 src/init.md这是理解为什么不能在 init 中启动 goroutine的更深层背景。一句话总结启动一个 goroutine 之前先回答两个问题——它什么时候停、我如何等到它停如果答不上来就不要启动它。赞分享文档【免费下载链接】uber_go_guide_cnUber Go 语言编码规范中文版. The Uber Go Style Guide .项目地址https://gitcode.com/gh_mirrors/ub/uber_go_guide_cn点击查看免费下载相关推荐Uber Go Style Guide 实战等待 Goroutine 退出的两种规范模式Uber Go Style Guide 实战等待 Goroutine 退出的两种规范模式 本篇技术指南围绕 Uber Go Style Guide 中 Wai文档教程代码质量LintUber Go 编码规范不要在 init() 中启动 goroutine用显式生命周期管理替代Uber Go 编码规范不要在 init 中启动 goroutine用显式生命周期管理替代 导读 本文讲解 Uber Go 语言编码规范中文版 uber文档不要 fire-and-forget 启动 goroutineUber Go 规范中的 goroutine 生命周期管理不要 fire and forget 启动 goroutineUber Go 规范中的 goroutine 生命周期管理 导读本文基于 Uber Go 语言文档上一篇Draw.io Mermaid插件安装与实战指南文本驱动图表一步到位下一篇免费在线AI分词计算器Tiktokenizer让Token成本一清二楚创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
