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

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

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

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

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

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

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

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

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

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

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

关闭期间的服务

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

破损的物品

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

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

泄漏检查错误报告

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

这是一个非常特定的领域，几乎不值得回答。动动你的脑袋。

航天飞机操作系统:不，不允许内存泄漏 快速开发概念验证代码:修复所有这些内存泄漏是浪费时间。

还有一系列的中间情况。

延迟产品发布以修复除最严重内存泄漏外的所有内存泄漏的机会成本($$$)通常会让“草率或不专业”的感觉相形见绌。你的老板付钱给你是为了给他赚钱，而不是为了得到温暖、模糊的感觉。

只有一种情况:由于不可恢复的错误，程序将自行终止。

这个问题已经讨论得令人作呕了。最重要的是，内存泄漏是一个bug，必须修复。如果第三方库泄露了内存，就会让人怀疑它还有什么问题，不是吗?如果你要造一辆汽车，你会使用一个偶尔漏油的发动机吗?毕竟，引擎是别人做的，所以这不是你的错，你不能修，对吧?

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

当应用程序关闭时，可以认为最好不要释放内存。

理论上，操作系统应该释放应用程序使用的资源，但总有一些资源是这个规则的例外。所以要小心。

退出应用程序的好处是:

操作系统只释放一个块，而不是很多很多小块。这意味着关机速度要快得多。尤其是在内存管理缓慢的Windows上。

只是退出的坏处其实有两点

很容易忘记释放操作系统没有跟踪的资源，或者操作系统可能会等待一段时间才释放。一个例子是TCP套接字。 内存跟踪软件将报告在退出时未释放的所有内容为泄漏。

因此，您可能希望有两种关机模式，一种是针对最终用户的快速且不友好的关机模式，另一种是针对开发人员的缓慢且彻底的关机模式。只是要确保两者都测试:)