关于Go协程泄漏的代码审查疑问及优雅退出模式的必要性探讨

嘿，这个问题问得特别实在——我日常做Go代码审查也经常碰到类似的纠结，咱们一步步拆解来看：

先看第一个信号处理协程：会不会泄漏？ #

完全不会，甚至连“泄漏”的前提都不成立。

你想啊，这个协程的逻辑是死等sigCh，收到信号后直接调用os.Exit(0)。只要os.Exit(0)执行，整个进程会被操作系统直接终止，所有正在运行的协程（包括这个等信号的协程）都会被瞬间回收，根本没机会留在系统里占用资源。就算进程是被外部强制终止的（比如kill -9），操作系统也会直接回收进程的所有内存和资源，协程自然也跟着没了。

退一万步说，就算没走到os.Exit(0)，比如程序在收到信号前就因为其他原因退出了，这个协程最多就是挂着等sigCh，但只要进程一没，它也会被销毁——这根本算不上泄漏。

再看第二个bootCh等待的协程：真的可能泄漏！ #

这个情况就不一样了。如果你的程序是长期运行的服务（比如API网关、后台服务），主协程会一直运行，那这个死等bootCh的协程就麻烦了：

• 如果bootCh永远不会有数据写入（比如触发bootCh的逻辑出问题了），这个协程会一直挂着，占用Go runtime的栈资源；
• 如果这个协程还持有其他资源（比如锁、数据库连接、文件句柄），这些资源也会被一直占用，没法被回收。

这就是真正的协程泄漏：进程还在正常运行，但这个协程永远无法完成任务，也无法被销毁，一直消耗系统资源。这时候你说的select + context模式就必须用上了，给协程一个明确的退出路径：

go func() {
    select {
    case <-bootCh:
        if err := monitorBootCh(); err != nil {
            errCh <- err
        }
    case <-ctx.Done():
        // 协程可以优雅退出，不会一直挂着
    }
}()

先搞懂：到底什么是“协程泄漏”？ #

很多人会把“进程退出时的协程”和“泄漏”混为一谈，其实两者完全不是一回事：

• 真正的协程泄漏：进程还在正常运行，但协程陷入了“永远无法被调度完成”的状态——比如死等一个永远不会有数据的channel、进入无退出条件的无限循环，或者等待一个永远不会触发的信号。这种情况下，协程会一直占用资源，拖慢程序甚至导致OOM。
• 进程退出时的协程：不管是os.Exit、信号终止还是程序崩溃，只要进程被销毁，操作系统会回收进程的所有资源，包括所有协程。这时候谈“泄漏”没有任何意义，因为所有东西都被系统清掉了。

回到你的核心疑问：要不要强制context + select模式？ #

我的建议是：对长期运行的服务类代码，必须强制；对短期运行的脚本类代码，可以灵活，但最好也养成习惯。

为什么？

1. 代码是会演化的：今天的临时脚本可能明天就被改成7*24小时运行的服务，今天的“小逻辑”可能变成核心模块。一开始就用优雅退出模式，能从根源上避免未来可能出现的泄漏问题。
2. 代码风格统一：统一的模式能让团队所有人都更容易理解代码，减少认知成本。比如所有协程都用select + context的方式处理退出，大家一看就知道这个协程有明确的退出条件。
3. 就算是信号处理协程，也能优化得更优雅：虽然它不会泄漏，但把sigCh和ctx.Done()结合起来，能让协程在ctx被其他地方取消时（比如主协程的错误处理）也能及时退出，而不是一直等sigCh：

   go func() {
       select {
       case <-sigCh:
           cancel()
           os.Exit(0)
       case <-ctx.Done():
           // 可以在这里做一些清理工作，然后退出协程
       }
   }()
   

最后给你的代码审查建议 #

• 第一个信号处理协程：现有逻辑不会泄漏，但可以建议优化成select + context的模式，让代码更统一、更健壮；
• 第二个bootCh协程：必须要求加上context的退出逻辑，否则在长期运行的场景下肯定会出问题；
• 给团队明确“协程泄漏”的定义，避免大家混淆概念，统一代码审查的标准。

内容来源于stack exchange