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

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

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

虽然大多数答案都集中在真正的内存泄漏(这是不正确的，因为它们是草率编码的标志)，但这个问题的这一部分对我来说似乎更有趣:

如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的解构器)，会怎样?只要内存消耗不随时间增长，那么当应用程序终止时(在Windows、Mac和Linux上)，是否可以信任操作系统为您释放内存?如果内存一直被使用，直到被操作系统释放，您会认为这是真正的内存泄漏吗?

如果使用了相关的内存，则在程序结束之前不能释放它。释放是由程序退出还是由操作系统完成并不重要。只要有文档记录，这样更改就不会引入真正的内存泄漏，并且在图中不涉及c++析构函数或C清理函数。未关闭的文件可能通过泄漏的file对象显示，但缺少fclose()也可能导致缓冲区不被刷新。

所以，回到最初的情况，在我看来，它本身是完全OK的，以至于Valgrind，最强大的泄漏探测器之一，只会在要求时处理此类泄漏。在Valgrind上，当您覆盖一个指针而没有事先释放它时，它会被认为是内存泄漏，因为它更有可能再次发生，并导致堆无休止地增长。

然后，就没有仍然可以访问的nfreed内存块了。我们可以确保在出口释放所有人，但这本身就是浪费时间。关键是他们之前能不能被释放。降低内存消耗在任何情况下都是有用的。

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

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

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

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

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

在程序的最后一行省略释放内存是完全可以接受的，因为释放它不会对任何事情产生影响，因为程序再也不需要内存了。

我的回答是没有。

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

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