如果您的代码有任何内存泄漏，即使是已知的“可接受的”泄漏，那么使用任何内存泄漏工具来查找“真正的”泄漏将会非常麻烦。就像留下“可接受的”编译器警告会使查找新的“真正的”警告更加困难一样。

我的回答是没有。

从理论上讲，如果你把东西弄得乱七八糟，操作系统会帮你清理干净(这很粗鲁，但由于计算机没有感情，这可能是可以接受的)。但是，您无法预测程序运行时可能发生的每一种情况。因此(除非您能够对某些行为进行正式的证明)，从专业的角度来看，造成内存泄漏是不负责任和草率的。

如果第三方组件泄漏内存，这是一个非常强烈的反对使用它的理由，不仅因为即将发生的影响，而且因为它表明程序员工作草率，这也可能影响其他指标。现在，当考虑遗留系统时，这是困难的(考虑web浏览组件:据我所知，它们都泄漏内存)，但这应该是标准。

在这类问题中，语境就是一切。就我个人而言，我不能忍受漏洞，在我的代码中，如果它们突然出现，我就会竭尽全力去修复它们，但修复漏洞并不总是值得的，当人们按小时支付我的报酬时，我有时会告诉他们，我的费用不值得我修复他们代码中的漏洞。让我给你们举个例子:

I was triaging a project, doing some perf work and fixing a lot of bugs. There was a leak during the applications initialization that I tracked down, and fully understood. Fixing it properly would have required a day or so refactoring a piece of otherwise functional code. I could have done something hacky (like stuffing the value into a global and grabbing it some point I know it was no longer in use to free), but that would have just caused more confusion to the next guy who had to touch the code.

就我个人而言，我一开始就不会以这种方式编写代码，但我们大多数人并不总是在设计良好的原始代码库上工作，有时你必须务实地看待这些事情。修复150字节泄漏所花费的时间可以用来改进算法，从而减少兆字节的内存。

最终，我决定为一个使用大约1g内存并运行在专用机器上的应用程序泄露150个字节不值得修复，所以我写了一条评论说它被泄露了，为了修复它需要改变什么，以及为什么当时不值得。

如果您的代码有任何内存泄漏，即使是已知的“可接受的”泄漏，那么使用任何内存泄漏工具来查找“真正的”泄漏将会非常麻烦。就像留下“可接受的”编译器警告会使查找新的“真正的”警告更加困难一样。

不，它们不是可以的，但是我已经实现了一些分配器、内存转储器和泄漏检测器，并且发现从实用的角度来看，允许人们将这样的分配标记为“就泄漏报告而言，不是泄漏”是很方便的……

这有助于使泄漏报告更有用……不要充斥着“静态范围内的动态分配不被程序退出释放”

理论上没有，实际情况要视情况而定。

这实际上取决于程序处理了多少数据，程序运行的频率以及它是否持续运行。

如果我有一个快速程序，读取少量数据进行计算并退出，那么就永远不会注意到一个小的内存泄漏。因为程序不会运行很长时间，并且只使用少量的内存，所以当程序存在时，泄漏将很小并被释放。

另一方面，如果我有一个处理数百万条记录并运行很长时间的程序，一个小的内存泄漏可能会在足够的时间内使机器停机。

对于有泄漏的第三方库，如果它们导致问题，要么修复库，要么找到更好的替代方案。如果不造成问题，这真的重要吗?