sync.Map实现的Collector工具引发内存与Goroutine增长问题排查

一、sync.Map的使用是否正确？ #

从API调用层面来看，sync.Map的使用是语法正确的：

• 调用LoadOrStore、Store等方法的方式符合sync.Map的线程安全规范，这些方法本身是原子操作，能保证多goroutine下的并发安全。
• 但用empty变量作为“正在加载”的占位符，这个逻辑设计存在缺陷：如果某个key的加载流程异常终止（未调用Store存入有效值），后续所有访问该key的goroutine都会进入等待循环，直到超时，持续消耗资源。

二、goroutine数量及内存占用过高的原因 #

核心问题在于等待逻辑的低效设计，具体如下：

• 轮询等待导致大量goroutine阻塞：当key处于“加载中”状态（status=2）时，每个访问该key的goroutine都会进入一个无限循环，每隔50ms轮询检查key的状态，直到超时或值被加载完成。大量goroutine同时访问同一个未加载的key时，会瞬间创建大量活跃goroutine，每个goroutine都占用栈空间等内存资源，直接导致内存占用飙升。
• 无高效的并发等待机制：当前设计没有使用sync.Cond这类信号量机制，让等待的goroutine休眠，直到值加载完成后统一唤醒，而是让每个goroutine独立轮询，这种方式不仅浪费CPU资源，还会持续占用goroutine资源。
• 超时前goroutine持续活跃：超时时间固定为5秒，在这期间，等待的goroutine一直处于活跃状态，即使值已经被成功存入，也需要等到下一次轮询才能退出，无法及时释放资源。

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