最近排查了一个内存泄漏问题，过程可谓一波三折，这里做个记录。本文只记录过程中遇到的坑，分析中使用的工具在另一篇文章中有介绍。
栈内存也可能增长
一般内存增长第一反应是堆内存有泄漏，但实际上栈内存也可能导致增长。我们的ASR引擎原本只有短会话场景，但这次新加了长会话。支持的方式也很暴力——短会话一直不释放（当然，做了相应的功能修改）。短会话中有很多栈上的变量，在整个会话中会一直存在。不仅如此，这些变量还会因为持续输入而不断变大（主要是一些vector和map）。由于短会话很快就释放了，原本这并不会带来内存问题。但是在长会话中，这导致内存几乎是线性增长！
这个问题是预料之内的，因此完整理了一遍代码，将其中持续存在的栈变量做了优化，内存增长确实大幅下降，从直线增长变成了偶尔涨一点。虽然涨的不多，但还是在涨啊！而剩下的这部分增长，耗费了我大量时间去排查！
tcmalloc 的坑
使用tcmalloc对内存进行分析（不用massif是因为这玩意的可视化工具需要GUI，而tcmalloc可以生成pdf等格式的可视化输出）。tcmalloc的使用方式见另一篇文章。
根据tcmalloc的输出，有三处堆内存增长。这三处是类似的，都是在一个线程中申请内存，然后传递给另一个线程使用。嘿嘿，这里用完没free，找到问题了，改完下班！然而事情并没有简单。在使用数据的线程中进行释放后，会报重复释放的错误！仔细分析后发现，线程管理模块会在线程结束后释放传递给线程的数据。经过试验，线程结束后确实及时释放了。
那么问题来了，为啥tcmalloc会指示这里存在问题呢？而且根据tcmalloc的结果来看，其他地方也没有明显的内存增长了。难道是释放的不对？这三处传递的是自定义类，可能没释放完全？经过一番分析和试验，可以确认释放是没问题的！
又按照tcmalloc的输出分析了很久，没有什么进展。怀疑是不是tcmalloc有问题，误报了。于是又换massif继续分析。可结果居然是一致的，massif也认为是这三个地方导致的增长。这下有点崩溃了，明明释放了呀。
在这里卡了好久没进展。最后想到，数据在A线程生产，B线程消费。当B线程消费的速度比A线程生产的慢，那么数据就会产生堆积。由于内存是在B线程结束后释放的，因此堆积的数据会导致内存增长。打断点看，生产的数据index到几千了，消费的数据index才几百，且index差值越来越大，证实了这一分析。
分析到这里，已经可以结束了，这个问题不用修——虽然可以在生产者和消费者之间加一些同步，但这只会将堆积提前，而不会消除堆积。因为最原始的输入是实时的，后续每一步都必须要能实时处理，否则就会在这一步产生堆积。问题的根源不在内存上，要解决这个问题，只能优化程序的效率，提高实时率。
但是，本着尽量和线上一致的原则，又用release编译的程序验证上述分析。在程序里加了打印index的功能。然而，打印的结果却与预想不一致！生产者和消费者几乎都是实时的，即使偶尔少量堆积，也很快就都被消耗了，不可能产生持续的内存增长！
那么tcmalloc看到现象为什么和release程序不一致呢？这是因为tcmalloc会极大的降低程序的性能（因为要对程序运行做记录），而输入仍然是实时的，使用tcmalloc会导致实时率不够，从而产生了数据堆积（massif也一样）。
也就是说，使用tcmalloc分析了这么久，其实都白分析了，因为它报的这个问题，其实是它自己导致的！
不要轻易动看起来“奇怪”的“蠢代码”
既然tcmallc/massif不能用，那么就只能继续靠“看”了。继续在代码里扣，发现有几个map很奇怪：这些map的key是一个整数，打断点看，这些整数还是递增的。为啥不用vector之类的呢？
第一节“栈内存也可能增长”中提到的会一直增长的栈变量包含这些map，当时是修改是当这些map涨到一定大小之后，每增加一个，就删掉一个早期的元素。会不会是这个修改导致的内存增长？map删除元素后内存不会立即释放，这个是有可能的。
那么把这些map改成循环队列吧！本来就不该用map。然而改完发现内存增长趋势并没什么变化。本以为这一波虽然没修好内存问题，但改了原来的“蠢蠢的”代码，也不算白干，结果却捅了个篓子。改成循环队列后只在长会话下进行了测试，没有测短会话。这个修改会导致短会话中出现数据覆盖的问题。
经过一番折腾，最后还是将这块改回了map。中间试图用队列、双队列等去实现，发现都有坑。看来最初写代码的人也是摸过这些坑，最后才用了map。
你以为你free了，内存就还给操作系统了吗？
上一波虽然很折腾，但起码弄清了一个问题——内存增长和map没什么关系。可是问题分析到这，似乎真的没什么可能导致增长的地方了。难道是监测脚本的问题？这个脚本大家都用了很久了，应该不会有什么问题。后来凯哥提出了一个猜想：我们虽然free了，但malloc库的实现并没有将内存还给操作系统。
从监测脚本的结果看，涨的是物理内存，虚存稳如大山。这是符合这个猜想的。但是如何验证呢？和凯哥查了一堆资料，也没找到很好的验证手段。后来瑞哥过来说可以用jemalloc替换glibc默认的ptmalloc库，jemalloc的申请和释放十分即时。直接从瑞哥那里拷了jemalloc.so过来验证，跑了几个小时，内存果然稳住了。趁着周末又跑了两天，依然稳如大山。真的是ptmalloc库的问题，难怪一直分析不出来。
总结
- 内存增长不一定是堆内存泄漏，持续存在的栈变量也可能导致内存增长。
- 数据的生产和消费分开，那么要考虑生产者和消费者不同步导致的数据堆积问题。
- tcmalloc、massif这类分析工具会导致程序性能大幅下降。在对实时率有要求的程序中，要考虑这一因素带来的影响。
- free、delete只是告诉malloc库“这块内存我不用了”，malloc库不一定会及时释放。
- 一些看起来很“奇怪”的代码，很可能是前人摸过的坑，改的话要慎重。
本文由 晓楼 创作，采用 知识共享署名4.0 国际许可协议进行许可。本站文章除注明转载/出处外，均为本站原创或翻译，转载前注明出处