我看到了和所有场景问题一样的问题，比如:当程序改变时，会发生什么?突然，这个小内存泄漏被调用了1000万次，而程序的结尾在不同的地方，所以它很重要?如果它在库中，那么请向库维护者记录错误，不要在您自己的代码中泄漏。

我完全同意JohnMcG的观点，只是想补充一点，我自己也有问题，无法及时发现真实的、潜在的严重内存泄漏，只是因为人们已经接受了良性的内存泄漏。随着时间的推移，这些病毒变得如此之多，在大量的良性病毒中发现严重病毒就变得越来越困难。

因此，至少为了你的程序员同事(也是为了你自己的未来)，请尽快消除它们。

只要您的内存利用率不随着时间的推移而增加，这取决于情况。如果你在服务器软件中做很多复杂的同步，比如启动阻塞系统调用的后台线程，那么完全关闭可能太复杂了。在这种情况下，备选方案可能是:

直到进程退出才清理内存的库。 您编写了额外的500行代码，并向类中添加了另一个互斥量和条件变量，以便它可以从测试中干净地关闭—但是这些代码从未在生产中使用，在生产中服务器只会因崩溃而终止。

我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。

在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。

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

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个字节不值得修复，所以我写了一条评论说它被泄露了，为了修复它需要改变什么，以及为什么当时不值得。

随着时间的推移，我看到的“良性”泄漏的数量一只手就能数得过来。

所以我的答案是肯定的。

An example. If you have a singleton resource that needs a buffer to store a circular queue or deque but doesn't know how big the buffer will need to be and can't afford the overhead of locking or every reader, then allocating an exponentially doubling buffer but not freeing the old ones will leak a bounded amount of memory per queue/deque. The benefit for these is they speed up every access dramatically and can change the asymptotics of multiprocessor solutions by never risking contention for a lock.

我已经看到这种方法在具有非常明确的固定计数的事情上有很大的好处，例如每cpu工作窃取deques，并且在Hans Boehm的C/ c++保守垃圾收集器中用于保存单例/proc/self/maps状态的缓冲区中有较小的程度，用于检测根集等。

虽然从技术上讲这是一个漏洞，但这两种情况在大小上都是有限制的，并且在可增长的循环工作窃取deque情况下，可以获得巨大的性能优势，以换取队列内存使用量增加2的有界因子。