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

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

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

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

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

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

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

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

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

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

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

关闭期间的服务

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

破损的物品

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

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

泄漏检查错误报告

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

考虑这样一种情况，该应用程序后来从另一个应用程序中使用，可以在单独的窗口中打开其中的几个应用程序，也可以依次打开其中的几个应用程序来执行某些操作。如果它不是作为一个进程运行，而是作为一个库运行，那么调用程序会泄漏内存，因为您以为您冷跳过了内存清理。

使用一些智能指针，自动为你做(例如scoped_ptr从Boost库)

No.

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

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

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

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

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

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

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

–

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

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

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

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

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

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

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

在这类问题中，语境就是一切。就我个人而言，我不能忍受漏洞，在我的代码中，如果它们突然出现，我就会竭尽全力去修复它们，但修复漏洞并不总是值得的，当人们按小时支付我的报酬时，我有时会告诉他们，我的费用不值得我修复他们代码中的漏洞。让我给你们举个例子:

I was triaging a project, doing some perf work and fixing a lot of bugs. There was a leak during the applications initialization that I tracked down, and fully understood. Fixing it properly would have required a day or so refactoring a piece of otherwise functional code. I could have done something hacky (like stuffing the value into a global and grabbing it some point I know it was no longer in use to free), but that would have just caused more confusion to the next guy who had to touch the code.

就我个人而言，我一开始就不会以这种方式编写代码，但我们大多数人并不总是在设计良好的原始代码库上工作，有时你必须务实地看待这些事情。修复150字节泄漏所花费的时间可以用来改进算法，从而减少兆字节的内存。

最终，我决定为一个使用大约1g内存并运行在专用机器上的应用程序泄露150个字节不值得修复，所以我写了一条评论说它被泄露了，为了修复它需要改变什么，以及为什么当时不值得。