写了八年Go才敢说：goroutine泄漏比内存溢出更阴险

八年前刚写Go的时候，我最怕的是内存溢出。OOM一出现，进程直接死掉，panic栈打在日志里，问题定位虽然麻烦，但至少它死得干脆。后来在生产环境里被教训得多了，才发现真正让人后背发凉的不是OOM，而是goroutine泄漏——它不吵不闹，内存曲线缓慢爬升，CPU看起来还算正常，服务也没有立刻挂掉，直到某一天凌晨，连接池被耗尽、调度器被拖垮、GC周期越来越长，整个服务像被抽走了氧气一样慢慢窒息。

这就是goroutine泄漏的阴险之处：它不是一次爆炸，而是一场慢性中毒。

Go的并发模型之所以迷人，是因为go关键字太便宜了。启动一个goroutine的成本低到几乎可以忽略，初始栈只有几KB，调度器还会动态扩容。这种设计让开发者很容易形成一种心理惯性：需要并发就go一下，需要超时就go一下，需要异步就go一下。但便宜不等于免费。每一个goroutine背后都有一份栈内存、一个调度单元、若干运行时元数据，更关键的是，它可能持有channel引用、锁、数据库连接、HTTP响应体、文件句柄。一旦这个goroutine永远阻塞在某个接收操作上，这些资源就永远不会释放。

而Go运行时对goroutine没有任何超时回收机制。它不会因为你阻塞了十分钟就主动杀掉你，也不会因为channel没人读就帮你清理。goroutine的生命周期完全由代码逻辑决定，运行时只负责调度，不负责善后。这一点和Java的线程池、和很多语言里的任务框架都不一样，那些框架至少还有队列长度、拒绝策略、超时中断这些兜底手段。Go把自由给了你，也把责任全部给了你。

我见过最典型的泄漏场景，是一个select里只写了case msg := <-ch，没有default，也没有超时分支。上游因为某个业务分支提前返回，不再往channel写数据，这个goroutine就永久卡在那里。代码review的时候看起来毫无破绽，因为单测里上游总是正常发送。可生产环境的异常分支远比单测丰富，一旦走到那个提前返回的路径，泄漏就开始累积。

还有一种更隐蔽的：向无缓冲channel发送数据，但接收方因为context取消提前退出。发送方阻塞在ch <- data上，永远不会被唤醒。这种泄漏在压测时几乎发现不了，因为压测流量规整、路径单一；只有真实用户的各种取消、超时、重试混在一起，才会把问题暴露出来。等到暴露的时候，往往已经积累了几十万个goroutine。

为什么说它比内存溢出更阴险？因为OOM有明确的触发点。内存涨到阈值，系统要么触发GC，要么被内核杀掉，监控会报警，日志会留痕，你知道出事了。而goroutine泄漏的早期表现极其温和：goroutine数量从几百涨到几千，内存从几百MB涨到一GB，P99延迟从50ms涨到80ms。这些变化淹没在日常波动里，很难引起警觉。等到数量突破十万，调度器的runqueue变长，GC的标记阶段要扫描的栈变多，停顿时间上升，吞吐量下降，整个系统进入一种“还能用但越来越慢”的状态。这时候你去查CPU，可能并不高；去查内存，也没到OOM；去查日志，没有任何error。问题像幽灵一样存在，却找不到抓手。

更麻烦的是，goroutine泄漏往往和业务逻辑深度耦合。它不是某个中间件配置错了，也不是某个依赖版本有bug，而是某段业务流程在特定异常路径下没有正确关闭并发任务。这意味着你无法靠升级组件解决，只能回到代码里，把每一条并发路径的退出条件重新推演一遍。而这种推演的成本，远高于修一个OOM。

那怎么办？我的观点是，不要把希望寄托在事后排查上，而要把约束前置到编码习惯里。

第一，任何启动goroutine的地方，都必须有明确的退出路径。这个退出路径不能依赖“上游一定会发送”这种假设，而应该由context或者done channel来驱动。启动方负责关闭，消费方负责监听，这是最基本的契约。

第二，channel的操作要有超时意识。select里除了业务分支，至少加一个ctx.Done()或者time.After。不要觉得加超时是冗余，超时不是对正常路径的怀疑，而是对异常路径的兜底。

第三，把goroutine数量纳入核心监控指标，和CPU、内存、延迟放在同一优先级。不要只看平均值，要看增长趋势。一个稳定运行的服务，goroutine数量应该在一个区间内波动，如果它呈现单调上升的锯齿形态，基本可以判定存在泄漏。

第四，善用pprof的goroutine profile。它能把当前所有goroutine的调用栈聚合出来，阻塞在同一个位置的goroutine会聚成一条记录。数量异常的那一条，往往就是泄漏点。这个工具不新鲜，但真正在故障发生时第一时间想到用它的人并不多。

第五，在代码规范层面明确一条红线：禁止在没有退出机制的情况下裸起goroutine。这条规则听起来很严，但比起线上被泄漏拖垮，严格一点是值得的。Go的简洁不应该成为偷懒的借口，go关键字越便宜，越需要敬畏。

写了八年Go，我越来越觉得这门语言的门槛不在语法，而在对并发生命周期的理解。语法三天就能上手，但goroutine的生死管理，需要长期的经验和纪律。内存溢出会让你疼一下，goroutine泄漏会让你在很长一段时间里持续地、隐隐地疼，而且你还说不清疼在哪里。真正成熟的Go服务，不是并发写得最多的那个，而是每一个goroutine都能被清楚交代去向的那个。