Go建站5年，内存泄漏？Goroutine池才是真解药

　　三个月之前，我被线上一个 Go 服务按在地上摩擦。那套东西是我从第 1 年建站一路带到第 5 年的，路由、中间件、RPC、消息消费全是 Go，平时 QPS 大概 4000，峰值能摸到 12000。问题说起来很俗：白天好好的，凌晨报表任务一来，RSS 从 1.8GiB 慢慢爬到 7GiB，容器 limit 是 8GiB，节点开始频繁 OOMKill。监控里 goroutine 数更离谱，从日常 3000 左右涨到 9 万多，pprof 堆里反而看不出明显的大块对象泄漏。

　　当时第一反应是不是 time.Ticker 没 Stop。

　　查了一圈，没有。后来又怀疑是 HTTP body 没关、context 没传到底、Kafka consumer rebalance 卡住，这些坑我都踩过，团队也加了静态检查和 review checklist，可这次火焰图里最扎眼的是一堆阻塞在 channel send、semaphore acquire、第三方 HTTP client 连接池上的栈。说白了，请求进来以后，每个 handler 为了做权限校验、画像查询、风控、推荐位补全，一口气起七八个 goroutine；下游慢的时候，这些 goroutine 不会凭空消失，全挂在那儿等，栈本身、关联的 request struct、序列化 buffer、trace span 都被带着走。你说这叫经典内存泄漏吧，也不完全是，因为下游恢复后一部分能退；你说不叫泄漏吧，内存和 goroutine 数就是不回头，业务已经快没了。

　　Go建站5年，内存泄漏？Goroutine池才是真解药——这句话我以前看了会觉得是标题党，毕竟 goroutine 本来就轻量，一个栈起步才 2KiB，动不动池化是不是 Java 味太冲了？但那次之后我的主观判断很明确：对高并发建站场景，无节制地 go func() 就是把调度器当资源池用，短期很爽，长期等于把背压、队列、超时、隔离全扔给运气。Goroutine 池不是银弹，可它确实是这类“泄漏不像泄漏、泄漏又确实泄漏”的真解药。

　　真正让我下决心改的是一次失败案例。

　　当时为了救火，有同事把下游 HTTP client 的 MaxConnsPerHost 从 16 提高到 200，还把超时从 800ms 放宽到 3s，理由很简单：既然 goroutine 在等连接，那就让更多请求同时发出去。结果第二天营销接口一放量，下游用户画像服务的 P99 从 120ms 飙到 1.8s，我们这层 goroutine 数 10 分钟冲到 14 万，内存直接撞 cgroup，三台 Pod 连续重启；更坑的是客户端还在重试，雪崩链路像拉链一样从推荐接口扯到登录后的首页。那个改动上线只活了 27 分钟，回滚时我手心都是汗。你看，很多所谓泄漏，本质是没有准入门槛，系统不知道什么时候该说“我接不住了”。

　　后来改造没搞什么花活，核心就是把散落在 handler、consumer、cron 里的裸 go func 收口。普通接口里的并发补全用统一的任务执行器，按业务域拆池：画像和权限这种强依赖一个池，最多 300 个 worker，队列 2000；推荐、埋点、非关键通知另一个池，最多 100 个 worker，队列 500，满了直接降级或者丢弃。每个任务必须带 context，外层超时 600ms，单次下游调用超时 250ms，池的等待时间也计入预算，等不到就别等。提交任务那里我还加了个很土但救命的指标：queue_wait_duration、pool_rejected_total、goroutine_in_pool，按接口和依赖名打 tag。没有这三个指标，池化只会把问题从“看不见的 goroutine”变成“看不见的排队”。

　　效果挺直接。

　　灰度一台 Pod 跑了 72 小时，同样的凌晨任务，goroutine 峰值压到 6800 左右，RSS 稳定在 2.2GiB 以内，不再出现每天一条斜线往上爬的图；推荐接口 P99 从 480ms 降到 310ms，因为请求不会在本地排几分钟才失败，画像服务抖动时错误返回得更快，用户端反而少转圈。还有个别人没怎么写过的细节：我们之前为了“性能”在 goroutine 里复用了一个 []byte 池，大对象被挂在长生命周期的 worker 旁边，pprof 看起来像 bufio 泄漏。改成池之后，任务边界清晰了，buffer 只在单次任务内租借和归还，最大 size 从无上限截断到 32KiB，大响应直接走临时分配，这才把那笔糊涂账抹平。

文章配图，仅供参考

　　下一步别一上来就引一个几千 star 的池库然后全局替换，那很容易从裸奔变成集体堵死。先抓线上 goroutine profile，看栈到底卡在哪个依赖；再挑一个泄漏最明显的接口，用带容量、超时、拒绝指标的小池灰度 48 小时，顺手把 context budget 和 HTTP body 关闭补齐。局限也摆在这儿：如果根因是死循环、channel 永不退出、全局 map 被无界缓存，Goroutine 池只能让故障晚一点爆，不能替你修 bug。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!