我的回答是没有。

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

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

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

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

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

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

许多人似乎都有这样的印象:一旦释放内存，它就会立即返回到操作系统，可以被其他程序使用。

这不是真的。操作系统通常以4KiB页面管理内存。malloc和其他类型的内存管理从操作系统获取页面，并在它们认为合适的时候对它们进行子管理。free()很可能不会将页面返回给操作系统，前提是您的程序稍后会误用更多内存。

我并不是说free()从不将内存返回给操作系统。这是有可能发生的，特别是当您正在释放大量内存时。但这并不能保证。

重要的事实是:如果不释放不再需要的内存，那么进一步的malloc必然会消耗更多的内存。但是如果先释放，malloc可能会重新使用释放的内存。

这在实践中意味着什么?这意味着如果你知道你的程序从现在开始不再需要更多的内存(例如它在清理阶段)，释放内存就不是那么重要了。但是，如果程序稍后可能分配更多内存，则应该避免内存泄漏——特别是那些可能重复发生的内存泄漏。

关于为什么在终止前释放内存是不好的，请参阅这条评论了解更多细节。

评论者似乎不理解调用free()并不会自动允许其他程序使用释放的内存。但这就是这个答案的全部意义!

因此，为了说服人们，我将演示一个例子，其中free()没有什么好处。为了便于计算，我假设操作系统以4000字节的页面管理内存。

Suppose you allocate ten thousand 100-byte blocks (for simplicity I'll ignore the extra memory that would be required to manage these allocations). This consumes 1MB, or 250 pages. If you then free 9000 of these blocks at random, you're left with just 1000 blocks - but they're scattered all over the place. Statistically, about 5 of the pages will be empty. The other 245 will each have at least one allocated block in them. That amounts to 980KB of memory, that cannot possibly be reclaimed by the operating system - even though you now only have 100KB allocated!

另一方面，您现在可以malloc() 9000多个块，而不会增加程序占用的内存量。

即使free()在技术上可以将内存返回给操作系统，它也可能不会这样做。Free()需要在快速操作和节省内存之间取得平衡。此外，一个已经分配了大量内存然后释放它的程序很可能会再次这样做。web服务器需要处理一个又一个的请求——保持一些“松弛”的可用内存是有意义的，这样你就不需要一直向操作系统请求内存了。

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

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

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的。

我的回答是没有。

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

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

我相信答案是否定的，永远不要允许内存泄漏，我有一些我没有看到明确说明的原因。这里有很好的技术答案，但我认为真正的答案取决于更多的社会/人类原因。

(首先，请注意，正如其他人所提到的，真正的泄漏是当您的程序在任何时候失去对已分配内存资源的跟踪时。在C语言中，当你malloc()指向一个指针并让该指针离开作用域而没有先执行free()时，就会发生这种情况。

你做决定的关键在于习惯。当你用一种使用指针的语言编写代码时，你会经常使用指针。指针是危险的;它们是向代码中添加各种严重问题的最简单方法。

当你在编程的时候，有时你会很专注，有时你会很累、生气或担心。在那些有点分心的时间里，你会更多地自动编码。自动驾驶效果不会区分一次性代码和大型项目中的模块。在此期间，您所建立的习惯将最终出现在您的代码库中。

所以，不，永远不要允许内存泄漏，就像你在换车道时仍然应该检查盲点一样，即使你是路上唯一的车。当你活跃的大脑分心时，好习惯可以让你避免灾难性的失误。

除了“习惯”问题之外，指针是复杂的，通常需要大量的脑力来在精神上跟踪。当涉及到指针的使用时，最好不要“搅浑水”，特别是当您是编程新手时。

还有更多的社交方面。通过正确使用malloc()和free()，任何查看您的代码的人都会感到轻松;你在管理你的资源。然而，如果你不这样做，他们马上就会怀疑有问题。

也许您已经发现内存泄漏在这种情况下不会造成任何损害，但是代码的每个维护者在阅读这段代码时也必须在自己的头脑中解决这个问题。通过使用free()，您甚至不需要考虑这个问题。

最后，编程是用一种明确的语言编写一个过程的心理模型，这样人和计算机就可以完全理解所述过程。好的编程实践的一个重要部分是永远不要引入不必要的歧义。

智能编程是灵活和通用的。糟糕的编程是模棱两可的。