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

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

退出应用程序的好处是:

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

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

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

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

我想以你的情况，答案可能是没关系。但是您肯定需要记录内存泄漏是一个有意识的决定。你不希望一个维护程序员出现，把你的代码放到一个函数中，然后调用它一百万次。因此，如果您决定泄漏是可以接受的，那么您需要为将来可能不得不在该程序上工作的任何人记录它(用大写字母)。

如果这是一个第三方库，你可能会被困住。但是一定要记录泄漏的发生。

但基本上，如果内存泄漏是一个已知的数量，比如512 KB的缓冲区，那么它就不是问题。如果内存泄漏持续增长，比如每次调用库调用时，内存都会增加512KB，但没有释放，那么可能有问题。如果您记录它并控制调用执行的次数，那么它可能是可管理的。但是你真的需要文档，因为虽然512不是很多，但是512超过一百万次调用就很多了。

此外，您还需要检查您的操作系统文档。如果这是一个嵌入式设备，那么操作系统可能不会从退出的程序中释放所有内存。我不确定，也许这不是真的。但这是值得研究的。

我想你已经回答了自己的问题。最大的缺点是它们如何干扰内存泄漏检测工具，但我认为这个缺点对于某些类型的应用程序来说是一个巨大的缺点。

我使用的遗留服务器应用程序应该是坚如磐石的，但它们有泄漏，并且全局变量确实妨碍了内存检测工具。这是件大事。

在杰瑞德·戴蒙德(Jared Diamond)的《崩塌》(Collapse)一书中，作者想知道那个人在想什么，他砍倒了复活节岛上的最后一棵树，而这棵树是他建造独木舟离开该岛所需要的。我想知道许多年前第一个全局变量被添加到我们的代码库的那一天。那是它应该被抓住的日子。

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

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

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

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

从历史上看，在某些边缘情况下，它在某些操作系统上确实很重要。这些边缘情况在未来可能会存在。

Here's an example, on SunOS in the Sun 3 era, there was an issue if a process used exec (or more traditionally fork and then exec), the subsequent new process would inherit the same memory footprint as the parent and it could not be shrunk. If a parent process allocated 1/2 gig of memory and didn't free it before calling exec, the child process would start using that same 1/2 gig (even though it wasn't allocated). This behavior was best exhibited by SunTools (their default windowing system), which was a memory hog. Every app that it spawned was created via fork/exec and inherited SunTools footprint, quickly filling up swap space.