即使您确定“已知的”内存泄漏不会造成严重破坏，也不要这样做。在最好的情况下，它会为你在不同的时间和地点犯下类似的、可能更严重的错误铺平道路。

对我来说，问这个问题就像问“我可以在凌晨3点没有人的时候闯红灯吗?”当然，在那个时候它可能不会造成任何麻烦，但它将为你在高峰时间做同样的事情提供一个杠杆!

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

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

首先，让我们把定义更正一下。内存泄漏是指动态分配内存，例如使用malloc()，并且所有对内存的引用都在没有相应的free的情况下丢失。制作一个简单的方法是这样的:

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

注意，每次在while(1)循环中，分配1024(+开销)字节，并将新地址分配给vp;没有指向之前malloc 'Ed块的剩余指针。这个程序保证运行到堆用完为止，并且没有办法恢复任何malloc'ed内存。内存从堆中“泄漏”出来，再也看不见了。

你所描述的，听起来就像

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

你分配内存，使用它直到程序结束。这不是内存泄漏;它不会损害程序，并且当程序终止时，所有的内存将被自动清除。

一般来说，应该避免内存泄漏。首先，因为就像你头顶上的高度和飞机库里的燃料一样，已经泄漏且无法恢复的内存是无用的;其次，在一开始就正确编码，不泄漏内存，比后来发现内存泄漏要容易得多。

我想以你的情况，答案可能是没关系。但是您肯定需要记录内存泄漏是一个有意识的决定。你不希望一个维护程序员出现，把你的代码放到一个函数中，然后调用它一百万次。因此，如果您决定泄漏是可以接受的，那么您需要为将来可能不得不在该程序上工作的任何人记录它(用大写字母)。

如果这是一个第三方库，你可能会被困住。但是一定要记录泄漏的发生。

但基本上，如果内存泄漏是一个已知的数量，比如512 KB的缓冲区，那么它就不是问题。如果内存泄漏持续增长，比如每次调用库调用时，内存都会增加512KB，但没有释放，那么可能有问题。如果您记录它并控制调用执行的次数，那么它可能是可管理的。但是你真的需要文档，因为虽然512不是很多，但是512超过一百万次调用就很多了。

此外，您还需要检查您的操作系统文档。如果这是一个嵌入式设备，那么操作系统可能不会从退出的程序中释放所有内存。我不确定，也许这不是真的。但这是值得研究的。

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

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

我很惊讶看到这么多关于内存泄漏的错误定义。如果没有一个具体的定义，关于它是否是坏事的讨论就不会有任何结果。

正如一些评论员正确地指出的那样，只有当进程分配的内存超出作用域，以至于该进程不再能够引用或删除它时，才会发生内存泄漏。

A process which is grabbing more and more memory is not necessarily leaking. So long as it is able to reference and deallocate that memory, then it remains under the explicit control of the process and has not leaked. The process may well be badly designed, especially in the context of a system where memory is limited, but this is not the same as a leak. Conversely, losing scope of, say, a 32 byte buffer is still a leak, even though the amount of memory leaked is small. If you think this is insignificant, wait until someone wraps an algorithm around your library call and calls it 10,000 times.

我认为没有任何理由允许在您自己的代码中泄漏，无论多么小。现代编程语言，如C和c++，不遗余力地帮助程序员防止此类泄漏，并且很少有好的理由不采用好的编程技术——特别是在与特定的语言功能相结合时——来防止泄漏。

对于现有的或第三方代码，您对质量的控制或进行更改的能力可能非常有限，这取决于泄漏的严重程度，您可能被迫接受或采取缓解措施，例如定期重新启动进程以减少泄漏的影响。

更改或替换现有的(泄漏的)代码可能是不可能的，因此您可能不得不接受它。然而，这并不等同于宣称它是OK的。