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

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

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

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

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

是的，内存泄漏可能是两害相权取其轻。虽然正确性很重要，但在执行完全内存释放时，性能或系统的稳定性可能会受到影响，并且释放内存和销毁对象所花费的风险和时间可能比仅仅退出进程更可取。

一般来说，在周围留下内存通常是不可接受的。理解代码运行的所有作用域是很困难的，在某些情况下，这可能导致泄漏成为灾难性的。

如果分配一些内存并一直使用到应用程序中的最后一行代码(例如，全局对象的析构函数)，会怎样?

在这种情况下，您的代码可能会移植到更大的项目中。这可能意味着您的对象的生命周期太长(它持续整个程序，而不仅仅是需要它的实例)，或者如果创建并销毁全局变量，它就会泄漏。

当应用程序终止时，是否可以信任操作系统为您释放内存

当一个短生命周期的程序创建大型c++集合(例如std::map)时，每个对象至少有2个分配。对CPU来说，遍历这个集合以销毁对象需要花费实时时间，而让对象泄漏并由操作系统清理具有性能优势。计数器，有一些资源没有被操作系统整理(例如共享内存)，并且不破坏代码中的所有对象会打开一些持有这些未释放资源的风险。

如果是第三方库将这种情况强加给您，该怎么办?

首先，我会为释放资源的close函数提出一个bug。是否可以接受的问题，是基于库提供的优势(成本、性能、可靠性)是否比使用其他库或自己编写更好。

一般来说，除非库可以重新初始化，否则我可能不会关心。

报告泄漏内存的可接受时间。

关闭期间的服务。这里需要在时间性能和正确性之间进行权衡。 一个破碎的无法被摧毁的物体。我已经能够检测到一个失败的对象(例如，由于异常被捕获)，当我尝试并销毁对象时，结果是挂起(持有锁)。 内存检查错误报告。

关闭期间的服务

如果操作系统即将关闭，所有资源将被清理。不执行正常进程关闭的优点是，用户在关闭时可以获得更快的性能。

破损的物品

在我的过去，我们发现了一个对象(并为该团队提出了一个缺陷)，如果它们在某些点崩溃，它们就会被破坏，该对象中的所有后续函数都会导致挂起。

尽管忽略内存泄漏是一种糟糕的做法，但关闭进程、泄漏对象及其内存比导致挂起更有效。

泄漏检查错误报告

一些泄漏检查器通过检测对象来工作，并以与全局变量相同的方式工作。它们有时会忽略另一个全局对象有一个有效的析构函数，在它们完成后调用，这将释放内存。

看来你对“内存泄漏”的定义是“我自己不清理的内存”。所有现代操作系统都会在程序退出时释放它。然而，由于这是一个c++问题，您可以简单地将所讨论的内存包装在适当的std::auto_ptr中，当它超出作用域时将调用delete。

Some great answers here. To add another perspective to this question, I'll address a case where memory leak is not only acceptable but desirable: in Windows drivers environment the developer provides a set of callbacks that are being run by the OS whenever required. One of the callbacks is a 'Shutdown' callback, which runs prior to system being shut off/restarted. Unlike standard situations, not only memory release is not necessary (system will be off in a moment), it's even discouraged - to make the shutdown as fast as possible and prevent the overhead of memory management.

No.

作为专业人士，我们不应该问自己“这样做是否合适?”，而应该问自己“这样做是否有一个好的理由?”“寻找内存泄漏是一种痛苦”并不是一个好的理由。

我喜欢把事情简单化。简单的规则是，我的程序应该没有内存泄漏。

这也让我的生活变得简单。如果我检测到内存泄漏，我会消除它，而不是通过一些复杂的决策树结构来确定它是否是“可接受的”内存泄漏。

它类似于编译器警告——警告对我的特定应用程序是致命的吗?也许不是。

但归根结底，这是一个职业纪律问题。容忍编译器警告和容忍内存泄漏是一个坏习惯，最终会给我带来麻烦。

举个极端的例子，外科医生把手术设备留在病人体内是可以接受的吗?

尽管移除设备的成本/风险可能会超过保留设备的成本/风险，并且可能在某些情况下它是无害的，但如果我在外科医生网站上看到这个问题，看到除了“不”之外的任何答案，这将严重削弱我对医疗行业的信心。

–

如果是第三方图书馆把这种情况强加给我，我会严重怀疑该图书馆的整体质量。这就像我试驾一辆车，发现其中一个杯托里有几个松动的垫圈和螺母——这本身可能不是什么大问题，但这表明我缺乏对质量的承诺，所以我会考虑其他选择。

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

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

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