除非“使用”的内存量不断增长，否则我不认为这是内存泄漏。有一些未释放的内存，虽然不是理想的，但不是一个大问题，除非所需的内存数量不断增长。

最佳实践是始终释放所分配的空间，特别是在编写旨在在整个系统正常运行期间运行的内容时，即使在退出之前进行清理。

这是一个非常简单的规则。以无泄漏为目标进行编程，可以很容易地发现新的泄漏。你会卖给别人一辆你自己造的车吗?你知道它一熄火就会喷到地上?：）

清理函数中的一些if () free()调用是廉价的，为什么不使用它们呢?

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

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

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

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

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

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

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

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

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

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

如果你在程序开始时分配了一堆内存，但退出时没有释放它，这本身并不是内存泄漏。内存泄漏是指当程序循环遍历一段代码时，该代码分配堆，然后在没有释放它的情况下“失去跟踪”。

事实上，在退出之前不需要调用free()或delete。当进程退出时，它的所有内存都被操作系统回收(POSIX当然就是这种情况。在其他操作系统上-特别是嵌入式的- YMMV)。

对于退出时不释放内存，我唯一要注意的是，如果你重构了你的程序，例如，它变成了一个等待输入的服务，做你的程序所做的任何事情，然后循环等待另一个服务调用，那么你所编写的代码可能会变成内存泄漏。

如果它是故意的，它真的不是一个泄漏，它不是一个问题，除非它是一个相当大的内存，或者可以增长到一个相当大的内存。在程序的生命周期内不清理全局分配是很常见的。如果泄漏是在服务器或长时间运行的应用程序中，随着时间的推移而增长，那么这就是一个问题。

通常，独立应用程序中的内存泄漏不是致命的，因为它会在程序退出时被清除。

对于那些被设计为不退出的服务器程序，您该如何处理?

如果你是那种不设计和实现资源分配和释放正确的代码的程序员，那么我不想与你或你的代码有任何关系。如果您不关心清理泄漏的内存，那么锁呢?你也把他们留在那里吗?你是否在不同的目录中放置了一堆临时文件?

泄露内存并让程序清理?不。绝对不是。这是一个坏习惯，会导致bug、bug、更多的bug。

自己收拾干净。你妈已经不在这里工作了。