对于检测程序代码中的资源泄露问题，市面上已经有很多工具了，但是今天我再来介绍一种新的方式，这种方式不需要安装任何工具或者特定的编译器开关，也不需要第三方库。
那就是：一直保持程序运行，直到泄露的原因自动水落石出。这是什么意思？

每日自动压力测试通常是工程开发中的一个常规部分。有一些软件开发团队使用屏幕保护程序作为触发器，其他团队使用自定义程序，还有一些团队需要手动启动压力测试，但无论如何，在你下班回到家后，你的计算机连接到测试服务器并接收一组整夜运行的测试。

这些压力测试经常出现的一件事是这样或那样的内存泄漏，由压力测试团队识别，因为程序的资源使用率异常高。但是如何调试这些故障呢？这些机器没有使用泄漏检测工具运行特殊的检测版本，因此你无法使用它。

相反，你可以一种新的检测思路：目标运行平台有着丰富的资源环境(target-rich environment)。

假设你的程序正在泄漏内存。连续大量使用十五小时后，程序开始出现内存不足故障。你显然在泄露一些东西，但是泄漏的具体是什么呢？

想想看：如果你泄露了一些东西，那么就会有很多。而你没有泄漏的东西数量很少。因此，如果你随机抓取进程快照，它很可能是一个泄漏的物体！用数学术语来说，假设程序的正常内存使用量为 15 MB，但由于某种原因，你已经用完了 1693 MB 的动态分配内存。由于其中只有 15 兆字节是正常的内存使用量，因此其他 1678 兆字节必须是泄漏的数据。如果从堆中转储随机地址，则找到泄漏对象的可能性大于 99%。

因此，随机抓取十几个地址并转储它们。你很可能会一遍又一遍地看到相同的数据模式。那是程序的泄漏点。如果它是一个具有虚拟方法的C++对象，转储 vtable 将快速识别它是什么类型的对象。如果是 POD(Plain Old Data) 类型，通常可以通过查找字符串缓冲区或指向其他数据的指针来识别它是什么。

最终结果可能会有所不同，但我发现这是一种非常成功的技术，可以把它想象成一种精神力量。

总结

我一直在 Topomel Box 中使用一个外挂式的第三方库来检测内存泄露，通过今天的文章，我明白了：我们可以什么也不做，就等它泄露，直至到达泄露原因是如此明显的时间点。
正所谓：无为而无不为。
共勉！

最后

Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一，里面有很多关于Windows的小知识，对于广大Windows平台开发者来说，确实十分有帮助。
本文来自：《The poor man’s way of identifying memory leaks》