背景
服务上线前进行常规压测，压测完通过监控发现进程占用内存久久无法下降，一度认为是内存泄露。根据内存泄露排查法，一顿pprof操作，但是发现服务所使用的内存并不是很高，那么回收掉的内存去哪了？还有为何监控显示的RSS值并非go服务runtime目前所持有的内存？带着这两个问题去阅读本文。
表现
选了一台4核8G的机器压测，发现压测结束后，CPU利用率已经降下来了，但是内存使用率一直稳定在3G左右（如下图内存使用率），然后根据pprof导出的heap结构进行分析，发现其占用内存只有仅仅百来兆不到。这两部分形成了很明显的对比，一度让我们怀疑代码是否有内存泄露。
压测结束后常驻内存图：
压测结束后pprof导出的heap结构：
排查思路
是否发生内存泄露
发现一
由于这个问题是稳定复现的，所以我这边直接在代码中加了点打印，单独起一个goroutine，跑一个for循环，间隔一定的时间调用一下下面的函数，打印出释放给操作系统的字节数。
functraceMemStats(){varmsruntime.MemStatsruntime.ReadMemStats(&ms)log.Printf("Alloc:%d(bytes)HeapIdle:%d(bytes)HeapReleased:%d(bytes)",ms.Alloc,ms.HeapIdle,ms.HeapReleased)}发现在压测过程中，HeapReleased的值其实基本上还是维持稳定上涨趋势至趋于平衡的，这个证明了服务一直在往操作系统归还内存，在这里进行ps和top进行观察，实际上该进程的RES并没有减少。但是Alloc值最终稳定在几十兆左右，证明程序持有并且未释放的内存块是降下来了的。那这里就出现了相驳的问题点。实际释放了，但是程序又没用上了，那内存归还到哪里去了呢？
发现二
持续压测，并没有发现内存持续增加，而是维持在一个相对稳定的高度。从这一点其实可以看出来并未发生内存泄露，毕竟内存泄露的话应该能观察到进程所占用的内存在不断上升，从这里可以大概猜测出被释放的内存应该是处于一个中间层，处于go runtime和系统OS之间，看到这里，就必须得去了解一下go的内存回收策略，才能准确的分析出问题所在。
go内存回收策略
触发时机
服务启动时，会在runtime的main函数启动一个goroutine，定时检测是否触发归还内存给OS的操作。
在heap进行扩容时，计算当前持有的内存和即将扩容的size之和是否达到清理阈值，然后会触发归还内存给OS的操作。（mheap.grow-->pageAlloc.scavenge）
手动调用debug.FreeOSMemory()方法，会触发归还内存给OS的操作。
runtime_debug_freeOSMemory-->mheap.scavengeAll-->pageAlloc.scavenge
核心逻辑
对于前面三种触发时机，最终都会落到sysUnused这个方法，对于不同的平台，sysUnused有不同的实现，这里咱们主要关注一下linux的实现mem_linux.go。这个函数里面有个核心调用madvise(addr, size, advice)，这个调用主要帮助咱们管理系统内存，比如分配、释放等等。看一下sysUnused的具体逻辑：
varadviseuint32ifdebug.madvdontneed!=0{advise=_MADV_DONTNEED}else{advise=atomic.Load(&adviseUnused)}iferrno:=madvise(v,n,int32(advise));advise==_MADV_FREE&&errno!=0{//MADV_FREEwasaddedinLinux4.5.FallbacktoMADV_DONTNEEDifitis//notsupported.atomic.Store(&adviseUnused,_MADV_DONTNEED)madvise(v,n,_MADV_DONTNEED)}在这段代码中有两个值_MADV_DONTNEED和_MADV_FREE需要关注一下，从大体上可以得知这两个值应该是释放内存的两个策略，根据注释，_MADV_FREE只有在linux内核版本4.5以上才会生效，否则会回退到MADV_DONTNEED进行调用。这里咱们可以去看一下具体文档去了解了解这两个参数的含义。
MADV_DONTNEED：最近一段时间不会再去访问这块内存空间，可以使用此操作，在成功使用这个操作后，内核将会在合适的时机去释放内存，但是进程的RSS（常驻内存）将会立即减少。但是要想再使用这一块的内存的话，内核就得重新分配一块新的空间了。
MADV_FREE：这个指令只能在linux内核版本4.5以上才能使用，此操作理论上只是打了一个标记位，只有在内核感觉到内存压力的时候才会将这些打标记的内存回收掉，分配给其他进程使用。这里进程的RSS不会立即减少。理论上MADV_FREE效率要高一些，毕竟内存的回收和分配都是会消耗系统性能的。
经过压测后，两个操作指令的选择不同，会导致监控视图显示不一样的结果，MADV_FREE会导致进程RSS会平稳在高峰，RSS不会得到立即释放，MADV_DONTNEED则会导致进程RSS会有明显的下降。而这里的选择又和debug.madvdontneed配置值有关，在go1.12之前，默认均选择的MADV_DONTNEED策略进行回收内存，可参考1.11.9版本。但是在go1.12~go1.15，官方默认选择MADV_FREE策略进行内存回收。直到go1.16，又改回了MADV_DONTNEED策略进行回收内存。
ifGOOS=="linux"{//OnLinux,MADV_FREEisfasterthanMADV_DONTNEED,//butdoesn'taffectmanyofthestatisticsthat//MADV_DONTNEEDdoesuntilthememoryisactually//reclaimed.Thisgenerallyleadstopooruser//experience,likeconfusingstatsintopandother//monitoringtools;andbadintegrationwith//managementsystemsthatrespondtomemoryusage.//Hence,defaulttoMADV_DONTNEED.debug.madvdontneed=1}这里有太多人吐槽改为MADV_FREE策略后，导致很多用户都没办法正常的通过一些监控工具去分析内存占用情况，很多人都认为自己的服务发生了内存泄露。感兴趣的可以去看一下相关的issues。
实验反证
使用MADV_DONTNEED回收策略，RSS会在很短的时间内进行下降，这一块很好测试，这里就不再补充相关测试案例了，只要你将go版本升级到go1.16以上，或者指定环境变量GODEBUG=madvdontneed=1，很快就能得出结论，如下图所示：
我这里主要想验证一下MADV_FREE的情况下，如果内核感觉到内存压力的时候，该进程的RSS是否会下降，被内核分配给其他进程进行使用（也就是实际上被标记MADV_FREE的内存块已经不属于go runtime持有了）。
写一段简单的代码来分配一段内存空间，并且手动调用FreeOSMemory去释放之前申请的内存：
funcmain(){n:=os.Args[1]max,_:=strconv.ParseInt(n,10,64)buf:=make([]byte,0)fori:=0;i<int(max);i++{a:=make([]byte,1*1024*1024*1024,1*1024*1024*1024)a[0]=1buf=append(buf,a...)}buf=buf[0:0]debug.FreeOSMemory()http.ListenAndServe(":8080",nil)}在16G的服务器上运行这段代码，选择合理的参数max，分配一段12G左右的常驻内存（假设这里是进程A），然后用另一个进程B去不断的分配内存，尝试去触发内核回收内存的阈值，结果会发现A进程的RSS确实会减少，也证明了MADV_FREE只有在内核感觉到内存压力的时候才会将这些打标记的内存回收掉，分配给其他进程使用（比如这里的进程B去使用）这一特点。如下图：A进程由最开始的11.8G RSS，降到了最后的 6.9G。实际上最后剩余的6G多也是可以被其他进程所使用的。
总结
所以这里并未发生内存泄露，只是命中了一个特殊的内存回收策略，查验了一下，压测的服务器内核版本为4.14，golang编译版本为1.15.10，刚好命中了linux默认的MADV_FREE回收策略。当然这里选择MADV_FREE回收策略有好有坏，好处是可以相对提升进程的性能，减少内存的分配，坏处就是可能给人造成一些误导，RSS没法迅速降下来，以为是发生了内存泄露。
最后解答一下最开始提的两个问题，其实可以归纳成一个问题：
为何监控显示的RSS值并非服务目前所使用的内存？按MADV_FREE方式回收掉的内存简单的来说只是给页面打了一个标记而已，并没有实际意义上归还给OS。
由于页面没有被OS回收，仍被计入进程的 RSS ，因此看起来进程的内存占用会比较大。但是实际上go runtime已经对这些内存不进行持有了。
PS：当然，最后选择用哪种方式去进行内存的回收，我个人感觉其实还是MADV_FREE比较好点，因为通过在页表中做标记的方式，延迟内存的分配和回收，可以提高内存管理的效率。
作者：marsjhe著作权归作者所有。