最近有个模块有内存泄露, 非常影响后台服务质量, 用valgrind也没有分析出原因(可能是分析的时候没有泄露), 就对着代码苦苦review, 发现有个基础业务文件存在内存泄露, 是近半年改动引起的。 代码只进行了new, 但没有delete操作。
我修改了有内存泄露的代码, 发布后, 擦, 系统立即告警, 傻眼了。 绝对不可能啊, 我不就是加了delete吗? 难道不应该加?
没办法, 只能回退发布的版本, 回退后, 告警立即停止。
可以得出结论: 告警与我发版本有关。
我仔细反复看new附近的逻辑, 也没有找到原因, 想问老大这是为什么, 但感觉又不太好, 还是希望单独解决问题。 这种级别的问题, 应该自己想办法独立处理掉, 不应该麻烦老大。 于是仔细review上个版本到这个版本的改动, 发现关键改动点就在于我加了delete(其余都是补充一些log), 难道我delete了不该delete的东西? 看逻辑, 也不是。
现在的蛋疼点在于: 从代码上上看, 我的改动绝对不会有问题; 从实际看, 我的改动就是有问题。
好吧, 还是相信实际, 但又找不出代码错在哪里
难道还有别的原因, 问问老大吧, 但又想, 不应该总是给老大反馈类似问题, 而应该反馈怎么解决类似问题。
好了, 我不纠结了, 原来代码不是new吗? 我直接用数组好了, 也不用delete, 也不担心数据被提前释放。 修改后, 发布, 两个告警问题解决了。
扯淡的new, 以后能不用就不要用了, 申请4096B甚至更大的的缓冲区, 完全没有用new的必要, 我讨厌这货!