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

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

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

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

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

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

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

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

退出应用程序的好处是:

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

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

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

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

我相信，如果你有一个程序，它将运行几秒钟，然后退出，这是可以的，它只是为个人使用。一旦程序结束，任何内存泄漏都会被清除。

当你有一个运行很长时间的程序并且用户依赖它时，问题就来了。另外，让你的程序中存在内存泄漏是一种坏的编码习惯，特别是如果它们可能在某一天将代码转换为其他内容的话。

总之，最好删除内存泄漏。

只要您的内存利用率不随着时间的推移而增加，这取决于情况。如果你在服务器软件中做很多复杂的同步，比如启动阻塞系统调用的后台线程，那么完全关闭可能太复杂了。在这种情况下，备选方案可能是:

直到进程退出才清理内存的库。 您编写了额外的500行代码，并向类中添加了另一个互斥量和条件变量，以便它可以从测试中干净地关闭—但是这些代码从未在生产中使用，在生产中服务器只会因崩溃而终止。