压测怎么查看内存泄露linux,linuxc、c++高并发服务内存泄露追踪分析

为什么top

-p出来的内存使用量没有下降呢？调用free就应该把由malloc申请的内存归还给操作系统，有错吗？通过网上查询得知，我对free的认识是错误的，由于free是由glibc库提供的，而glibc默认采用ptmalloc进行内存的分配。ptmalloc为了提升性能，不会立刻把内存归还给操作系统，归还给操作系统的条件是很苛刻的。毕竟，与系统底层通信的代价是昂贵的，如果动辄就直接操纵大量小块内存，就相当于频繁地与系统调用进行通信，这样显然会降低程序的运行效率。将小块内存放入brk维护的一个堆中，就相当于实现了一块缓存(cache)，用完了可以先攒起来，到时候可以一起归还给系统。不过，由于它的实现相对来说还是比较简单，只维护了堆顶的一个指针。因此想要归还给系统的话，必须从顶向下，依次归还。想象一下这种情况，假如堆顶有块内存一直被占用着，而下面的所有内存都已经没用了。那下面的这些内存，可以归还给系统吗？很遗憾，这种设计决定了答案是不可以。这就出现了“洞(Hole)”的问题。

问题已经水落石出，不过，还是没有十足的把握，毕竟没有直接证据呢？还好glibc提供了一个malloc_trim()这个函数，头文件是，这个函数将会重新整理内存，释放符合条件的已经归还给glibc，但未归还给操作系统的内存。为了证实推论，我把malloc_trim(0)放入信号处理函数中，当压测程序结束运行之后，待cpu使用率为0.0%的时候，我触发了一个信号。内存奇迹般的下降了，以下是真是测量数据：

调用malloc_trim之前：

调用malloc_trim之后：

物理内存的降幅十分明显，至于虚拟内存为什么没有释放，可能和malloc_trim的工作原理相关。

总而言之，想要根治这类问题，就需要在应用层使用内存池，避免频繁使用malloc与free，这种由于glibc的原因造成的内存泄露，十分隐蔽，希望有类似问题困扰的读者不妨可以试一试。