目录
最近做的项目,频频出现内存泄漏问题,感觉就像是老头疼,刚治好了这,那又犯了。
以下仅是对个人项目里的内存泄漏问题做个记录总结,并非系统性技术分享。
一、罗列项目中出现内存泄漏的地方
1.1 new delete
基本上只要new出来的内存,都已经delete掉了。但是还是出现了以下问题:
(1)异常场景分支忘记释放
但是还是有遗漏的:在一些小概率的异常场景分支,直接return结束了函数,但是忘记了delete掉函数内申请的内存。
(2)new type[] 与delete[]
申请内存时,是以new type[] 形式申请的内存,释放时需要使用delete[]才能释放彻底。
1.2 打开的文件未关闭
使用fstream读磁盘文件的时候,只打开了文件流,但是没有使用.close()函数关闭。
1.3 打开的磁盘路径没有关闭
使用opendir()打开文件夹路径,但是没有用closedir()函数关闭
14 调用的第三方接口,内部申请了内存,但是没有释放
有的第三方接口,内部申请了内存等资源,但是不会自动回收,所以还需要调用其对应的资源释放接口。如tensorRT的creatInferRuntime()、deserializeCudaEngine()、createExecutionContext()等接口,需要使用destroy()函数将其销毁;
1.5 全局变量只往里塞数据,但是没有及时清理
一些存放数据的全局变量,例如我项目里的目标特征库,虽然已经有了一些逻辑会根据不同业务场景清理数据缩减其规模,但是还是建议,直接有一个暴力的条件判断以防不测:定期判断全局变量的容量大小,当容量超过某特别大的阈值时,暴力缩减存储的数据甚至清空。
二、导致内存泄漏很难定位解决的原因
2.1 工程技术链路长,模块多
没办法,不过代码能分成模块也挺好,至少做代码注释定位问题时很方便。
2.2 很多代码不熟悉
集成的多个代码模块,都是网上下载的开源代码,对其中逻辑不熟悉。
以后找资源的时候,尽可能找一些靠谱的。
2.3 很难复现
这一点很重要,能成功复现出问题,基本上就解决一半问题了。
有的内存泄漏不是必现,可能是某个小概率条件分支里有泄漏。
2.4 个人能力菜
三、总结内存泄漏问题的解决流程
3. 1 使用内存泄漏定位工具,先筛查一遍
工程如果比较大,直接刚代码肯定是不明智的。
注意工具不是万能的,但是能查出来一处泄漏,也是有帮助的。
内存泄漏定位工具(linux):valgrind、asan(AddressSanitizer)、Sonarqube、vscode-cppcheck插件等;
内存监测工具(linux):top、Telegraf+Influxdb+Grafana三件套
内存泄漏工具windows:VS2015性能探测器、VLD嵌入式分析、windbg工具udmh解决定位内存泄漏方法、LeakDiag内存泄漏分析LDGrapher查看
3.2 手动搜索new/delete、malloc/free
new与delete、malloc与free都要成对使用,注意异常场景下别忘记释放(每个分支都要闭环)。
3.3 代码分块注释与测试
看上去最低效,但是个人感觉是最有效的,尤其是上面方法都用完以后还是有泄漏,但是兜兜转转,还是祭出了本大招。
逐块注释代码,然后运行看是否有泄漏,不断缩小可疑代码的范围。
最后:代码虐我千万遍,都是泪啊。。。