Go协程工作队列内存泄漏问题排查求助

核心原因推测 #

从代码逻辑和内存泄漏现象来看，任务对象无法被GC回收的核心问题大概率是存在未被切断的长期引用链，以下是具体拆解：

1. process函数持有任务对象的长期引用 #

这是内存泄漏最常见的诱因。如果wc.process(ctx, wi)方法将任务对象wi存储到了任何长期存活的结构中——比如Sender结构体的成员变量、全局缓存、未正确清理的内部队列，或者其他生命周期与应用一致的容器——那么这些任务对象会持续被引用，永远无法被GC回收。pprof明确指向任务对象占用内存，说明对象本身未被释放，大概率存在这类隐藏的引用。

2. Slice底层数组的隐式引用（可能性极低） #

Go的slice基于底层数组实现，dequeue返回的items会引用整个底层数组（即使slice长度小于容量）。但只要items变量在循环结束后超出作用域，这个引用就会消失，底层数组和其中的任务对象都会被GC回收。从现有代码看，不存在其他地方引用该底层数组的情况，因此这个原因的概率极低。

3. Context取消时的临时泄漏（非OOM根源） #

当ctx被取消时，run函数会直接return，此时当前批次未处理的任务会被items变量引用。但这种情况只会导致单次内存泄漏，不会持续累积到OOM，因此不是问题的核心。

调试与解决步骤 #

1. 排查process函数实现
   重点检查process是否将任务对象存入了长期存活的结构：

   • 是否把wi添加到Sender的某个字段（比如wc.pendingTasks这类未清理的列表）
   • 是否存在全局缓存、池化结构持有任务对象
   • 是否有闭包、回调函数捕获了wi且未被释放

2. 显式切断items引用（调试手段）
   在run函数的循环末尾添加items = nil，强制清空对任务slice的引用，帮助GC更快识别可回收对象：

   // attempt to drain the current queue
   for _, wi := range items {
       wc.process(ctx, wi)
       if ctx.Err() != nil {
           items = nil // 退出前显式置空
           return
       }
   }
   items = nil // 循环结束后置空
   

   这一步是调试手段，无法解决根源问题，但可以验证是否是引用未及时释放的问题。

3. 用pprof追踪引用链
   使用Go的pprof工具进一步分析内存引用：

   • 生成heap profile：go tool pprof -http=:8080 ./your-binary heap.pprof
   • 查看任务对象的引用路径，找到持有这些对象的具体结构，精准定位泄漏点

4. 验证队列逻辑正确性
   确认dequeue方法确实将q.items置为nil，没有残留引用；同时检查enqueue的信号逻辑是否正常，确保所有任务都能被及时取出处理。

内容的提问来源于stack exchange，提问作者Mordachai