一次伪内存泄露

背景

压测发现，机器人关闭后，内存没有减下来，初步判断是内存泄露

内存泄露排查 - Review 代码

包括

• static 静态变量
• extern 全局变量
• 单例中的容器字段

没有发现异常的地方

内存泄露排查 - 使用 gperftools dump 内存分布情况

gperftools 相关知识可以参考： https://github.com/fananchong/gperftools_sample

使用过程如下：

• 登录几百个机器人后
• dump 一次
• 全部登出
• 再 dump 一次

第一次 dump 出来，结果如下：

第二次的 dump ，结果如下：

500 机器人登录后，内存涨到 12.9 M ， 全部登出，内存回到 0.8 M

与压测时的监视曲线完全不符

因此，判断可能不是内存泄露，排查方向错了

内存泄露排查 - 了解内存管理器运作机制

于是百度搜了下诸如： glibc 内存管理 、 tcmalloc 内存管理

会发现，也有人遇到相同情况：

• https://www.cnblogs.com/lookof/archive/2013/03/26/2981768.html

才发现是内存管理器在作怪

总结

判断是否内存泄露，除了文中所说的：

• Review 代码
• 使用内存检查工具

这些比较耗时的工作量外

通常，可以初略的观察下内存占用曲线，就可以大致判断

比如，内存占用曲线是这种模样的，阶梯型的，一定是内存泄露：

                                         +-------------------------------------+ 4G
                                         |
                                         |
                                         |
                   +---------------------+
                   |
                   |
                   |
                   |
1G +---------------+

再如，内存占用曲线是这种模样的，回归某水平线型的：

                                         +------------+  4G
                                         |            |
                                         |            |
                                         |            |
                   +---------------------+            |
                   |                                  |
                   |                                  |
                   |                                  +---------------------+
                   |                                                        |
1G +---------------+                                                        +--------------------+ 1G

虽然也是有 1G 内存未释放，通常需要做进一步排查，切勿轻言一定未内存泄露