Go最新从真实事故出发：golang 内存问题排查指北，企业级项目实战讲解

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

从中可以发现，metircs.flushClients()占用的内存是最多的，去定位源码：

func (c *tagCache) Set(key []byte, tt *cachedTags) {

if atomic.AddUint64(&c.setn, 1)&0x3fff == 0 {

// every 0x3fff times call, we clear the map for memory leak issue

// there is no reason to have so many tags

// FIXME: sync.Map don’t have Len method and setn may not equal to the len in concurrency env

samples := make([]interface{}, 0, 3)

c.m.Range(func(key interface{}, value interface{}) bool {

c.m.Delete(key)

if len(samples) < cap(samples) {

samples = append(samples, key)

}

return true

}) // clear map

logfunc(“[ERROR] gopkg/metrics: too many tags. samples: %v”, samples)

}

c.m.Store(string(key), tt)

}

发现里面为了规避内存泄露，已经通过计数的方式，定数清理掉 sync.Map 存储的 key 了。理论上不应该出现问题。

排查结果

没有代码 bug 导致内存泄露的问题。

推测三：怀疑是 RSS 的问题

排查过程

这时注意到了一个事情，在 pprof 里看到 metrics 总共只是占用了 72MB，而总的 heap 内存只有 170+MB 而我们的实例是 2GB 内存配置，占用 80%内存就意味着 1.6GB 左右的 RSS 占用，这两个严重不符（这个问题的临时解决方法在后文有介绍），这并不应该导致内存占用