记一次c++程序逻辑引起的内存泄漏

今天发了个日常，别看是日常，日常的内容挺大的，SK（内部搜索用到的一个common 组件）内存泄漏修复。内存泄漏？为啥会有内存泄漏这样的问题暴露到了外网呢？本着虽然 测试 不能穷举，但是应该总结漏出去的问题的原因，避免同样的问题多次犯错，尽量减小这样的事情的发生。找开发沟通了一下，颇有点心得，记录下来，用于后面自己回归，回忆和思考。
   由于当前的 web 互联网 行业都在提倡一个观念，就是小步快跑的概念，那么在此概念下就出现了版本发布很频繁的现象，这个时候对于开发，测试的挑战都很大，对于测试，要保障版本的尽快发布，开发要保障版本的尽快实现和提测，对于bug的修复，验证，合并代码，总之，“忙”这个字代表了一切......
   为什么要说下小步快跑和其带来的现象呢？跟我要说的这次主题有什么关系？有关系，跟我们分析，定位内存泄漏的原因有关系。为什么？接着往下看，由于小步快跑，频繁迭代带来的影响，当出现内存泄漏的现象时，由于内存泄漏分为偶发性，常规性，一次性等特征，往往已经有多个版本的代码已经发布出去了，那么到底是哪个版本发布出去的代码造成的内存泄漏呢？？？这个就是一个问题了，那么怎么办？这个就要提倡一种思想：“把一切都监控起来”。我们这里通过查看对于线上机器的监控系统，发现监控的线上主机内存的几个波动大，斜率大的点，针对这几个点确定这一时期发布了哪些版本？代码做了什么修改？该类版本发布出去之后是否会有新的请求？新的请求是什么？没新的请求，那么旧有的请求是哪些构成的？弄清楚了这些，那么就拿到了后期分析的第一手资料。紧接着，观察该内存变化曲线，是斜率，抖动一直都很大还是到了某一时期，中间有一定的回落和平缓？如果有的话，进入该拐点时期，我们的程序，版本上，请求上，处理上又做了什么修改和变化？没办法，对于这种版本频繁发布，代码频繁合并，更新的行业应用，定位问题的过程感觉的确比较的苦B，是否也可以借助一切都监控起来呢？（可以，这个也是我们测试团队后面要做的事情，就是（automation+monitor+report）)至于具体是怎么做的，现在还只有一个大概，就是针对sk此服务process进行持续的请求发送，发送的过程中要注意请求的粒度的划分，以方便问题的发现，定位（哪个业务）为基准，然后再通过将问题暴露，与开发协同一起将问题进行更深入的定位和修复。
  对于内存泄漏，有很多的内存泄漏检测工具，比如这里的c++就有valgrind，但是是不是我们用valgrind就可以了呢？？？答案是，NO。valgrind作为一款工具，它的原理就是记录下程序运行的时候申请的内存，在程序关闭之后，查看该处内存是否有被释放，如果没有那么就会报错。在这个处理的过程中，我们观察过，valgrind会使得运行一次花费的时间过长，影响版本的发布，而且report的报告中有很多的信息是我们不需要的，几千上万条信息中查找我们需要的信息，难度太坑爹啦，所以，要找到能达到目的的简单的方法，这里介绍一下，unix操作系统对于所有的进程当前使用的资源情况其实都记录在了/proc相应的目录下面了，那么对于此次的内存泄漏的问题的监控，可以在结合后期我们要做的监控，测试框架（性能）的基础上再加上一个一定频率的收集或显示/proc/procis/status的命令脚本就可以了，在这里我们主要还是关注三个数据（对于内存、内存是否泄漏来说），三个数据和其对应的含义如下：
1、VmSize：当前procid使用的虚拟内存数。如果此值很高则表示当前内存存在不足，只有物理内存不足的情况下OS才会使用虚拟内存
2、VmRSS：当前procid使用的物理内存量
3、VmD：当前procid使用的heap内存的量

如果这三者随着测试时间一直在增加，那么95%以上可以肯定对应的业务请求存在内存泄漏，这个时候可以找开发协助定位和确认问题啦：）

关键点：拐点，明确版本修改内容，请求的变化等
       熟练unix相关的性能分析命令和命令显示内容各指标含义