如何排除内存泄露问题

---

一、protobuf可以使用缓存吗解决了次要版本之间的升级点问题。对于这个内存已经增加了几个月的模块来说，直接检测问题是非常困难的，而且投资会非常大。为了尽快开始模块功能的迭代，我们最初主要致力于解决近期模块上线的功能问题。希望通过解决这些较小的增量问题，能够发现对记忆的影响。经过2天的调查，没有任何发现。
结合模块内存的历史表现以及近期升级功能的排查结果，我们认为模块内存的增长可能不是泄漏，而是在持续调用过程中部分数据不断增加，导致在连续的内存泄漏中。理论上，程序的内存使用量可以在足够长的时间后稳定下来。然而，由于程序的物理内存，我们无法观察到内存何时稳定。
排除数据热加载导致的内存泄漏。离线环境下，所有数据文件都不会更新，因此排除了数据热加载导致的内存泄漏。
每个模块都经过逐步核。在解决了小版本间升级点失败的问题后，我们调整了排查方法，将程序中的各个子模块（简称模块）一一排除。总共有13个模块，如果一一检查的话，会花费很多时间。实施过程中采用二分法进行分析。具体来说，就是某个模块的中间点，删除这个模块和下一个模块，看看该模块的内存变化。去掉中间模块（含）之后的模块后，发现内存增加率下降了30%，说这个模块之前的模块有70%已经泄露了。通过对这些模块进行分析，发现其中某个模块（简称模块A）最为可疑。
通过UT验证内存升级。在识别之前泄露的关键模块的过程中，我们使用了真实环境中的验证方法。这种方法的缺点是耗时。启动程序并观察需要很长时间，并且每天只能验证一个版本。为了加快问题验证速度并与模块特性结合起来，我们采用UT编写方式来调用模块进行验证。每次验证仅需30分钟，大大加快了问题验证速度。
使用监控并查找问题。通过写UT，我们排除了moduleA中的两个子模块。另外，我们发现modulA的单网络内存增长速度占到了线上单线程内存增长的30%，这里可能存在严重的问题。在UT中，我们监控merged_data，这是该模块中最重要的数据结构（存储了其包含的子模块的特征数据）。我们发现merged_data数据结构的内存有所增加，并且增加量与moduleA的总量一致。至此，我们已经确认了merged_data类型结构体内存增加了。模块中存在很多此类数据结构，我们有理由怀疑模块整体内存增加是由于这种情况造成的。

---

二、怎样发现内存泄露?1.如何检查内存泄漏：
oc-一个简单的内存泄漏和malloc调试库，适用于Linux和Solaris下的C和C++程序。
　-Linux下检测内存泄漏的程序。
CH-由JohanLindh编写，是一个开源的C语言内存错误检测工具，主要通过gcc的前身实现。
nd-调试和分析Linux程序，针对用C和C++编写的程序。
grind-可视化工具，用于分析Cachegrind和Calltree生成的数据以及可靠性错误。PurifyPlus将内存错误和泄漏检测、应用程序性能分析、代码覆盖率分析等结合到一个完整的工具包中。
2、内存泄漏简介：
内存泄漏也称为“内存泄露”。该内存单元始终处于繁忙状态。直到程序结束。（其实说白了就是内存空间使用后没有被回收），这就是所谓的内存泄漏。
内存泄漏的比喻是“操作系统可以提供给所有进程的存储空间正在被某个给定的进程清空，最终的结果是程序运行的时间越长就越和”。更多的存储空间，最终所有存储空间耗尽，整个系统崩溃。所以“内存泄漏”是从操作系统的角度来看的。这里的存储空间不是指物理内存，而是指虚拟内存的大小，这个虚拟内存的大小取决于磁盘交换区的大小。如果程序请求的一块内存没有任何指针指向它，那么内存就会泄漏。