【内存泄漏bug 调试及解决历险记】

最近，在测试流媒体视频播放时，发现了一件奇怪的事，每打开一定路数(如12路或20路)的视频时，内存都会按MB数量级增加，尤其是在进行自动切屏时，内存增加尤为明显，可以看出这是存在明显内存泄漏。怎么解决这一问题？首先按照时间先后顺序，依次往前查找曾经测试过的不存在内存泄漏的版本，找到相应版本测试确定没有内存泄漏后，将该版本的播放模块文件与现在存在内存泄漏的播放模块文件用文件比较工具进行比较，没有发现明显的产生内存泄漏的地方，无法根据不同进行修改，只好将两个播放模块文件互换着测试，结果发现原来产生内存泄漏的工程还是存在内存泄漏，而原来没有内存泄漏的工程，还是没有内存泄漏。
这就奇怪了！未必，内存泄漏出现在主模块的逻辑处理部分呢？那么，要怎么验证问题出在主模块部分？于是，想到了一个办法，将主模块逻辑处理部分全流程开放，播放模块部分不执行视频播放，如果内存还是一样的增加，就能确定问题出在主模块。结果发现长时间自动切屏运行内存并没有一直增加，始终保持在一定范围波动，而一打开播放器，就会出现内存一直增长的泄漏现象，并且，内存增长到系统给程序分配的空间限制，导致无法分配内存，打不开视频，继续执行自动切屏时，内存没有继续再增长，这说明主模块部分没有内存泄漏现象，基本可断定是播放模块的问题。但同样的播放模块，为什么在别的工程中没有内存泄漏呢？而后来测试的一个新的相对较为复杂的工程，使用同样的播放模块文件，没有出现内存泄漏的现象，又让人怀疑不像是播放模块的问题，倒更像是主模块的问题。那么，内存泄漏问题到底出在哪？正当准备自己在主模块部分采用一点点叠加迭代或递减方式查找并解决问题(即便找到并解决了问题又如何，播放模块的内存泄漏隐患还是没有消除)时，我的搭档似乎在播放模块找到了问题的所在(在每次释放内存时，只释放了存储视频参数的结构体，而其中真正存放视频数据的数据体并没有释放，而通常的情况是应该首先释放结构体中的数据体，然后才是结构体，这样视频数据才能释放干净，否则，在某些特定情况下，就会出现视频数据释放不干净，这实际上留了一个产生内存泄漏bug的隐患)，后来长时间测试验证确实如此。这里，这个搭档在技术上踏实，对自己写的东西有个正确的认知，知道问题的漏洞在哪，并且不诡辩的态度，值得现在很多年轻技术开发从业者学习。如果他诡辩采取非此即彼的排除法，说不是他的问题，你也拿他没辙，除非你找出该问题的漏洞，让他心服口服。而解决问题过程中发现的这种模棱两可的现象，让人想起了科学上一个著名的双缝试验，以及薛定谔的猫——不确定性问题。事实上，很多不确定，并不仅限于文科领域，在理工科领域很多技术上的问题，也存在这种不确定。由于人类认知和时间、精力的有限，人们无法穷尽所有问题，并找到一个明确的确切答案。很多问题你可以说是此的问题，也可以说彼的问题，并没有一个该问题的明确界限，以及确定是哪里的问题。