我相信有人能想出一个理由说“是”，但不会是我。 与其说“不”，我要说的是，这不应该是一个“是”或“否”的问题。 有许多方法可以管理或控制内存泄漏，许多系统都有内存泄漏。

在离开地球的设备上有NASA的系统为这个做了计划。系统会经常自动重启，这样内存泄漏就不会对整体操作造成致命影响。这只是一个遏制的例子。

理论上没有，实际情况要视情况而定。

这实际上取决于程序处理了多少数据，程序运行的频率以及它是否持续运行。

如果我有一个快速程序，读取少量数据进行计算并退出，那么就永远不会注意到一个小的内存泄漏。因为程序不会运行很长时间，并且只使用少量的内存，所以当程序存在时，泄漏将很小并被释放。

另一方面，如果我有一个处理数百万条记录并运行很长时间的程序，一个小的内存泄漏可能会在足够的时间内使机器停机。

对于有泄漏的第三方库，如果它们导致问题，要么修复库，要么找到更好的替代方案。如果不造成问题，这真的重要吗?

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

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

退出应用程序的好处是:

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

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

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

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

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

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

我完全同意JohnMcG的观点，只是想补充一点，我自己也有问题，无法及时发现真实的、潜在的严重内存泄漏，只是因为人们已经接受了良性的内存泄漏。随着时间的推移，这些病毒变得如此之多，在大量的良性病毒中发现严重病毒就变得越来越困难。

因此，至少为了你的程序员同事(也是为了你自己的未来)，请尽快消除它们。

在应用程序运行后清理操作系统在概念上没有问题。

这实际上取决于应用程序以及它将如何运行。在需要运行数周的应用程序中不断发生的泄漏必须得到处理，但是一个不需要太多内存就能计算结果的小工具应该不是问题。

许多脚本语言不垃圾收集循环引用是有原因的……对于它们的使用模式，这不是一个实际的问题，因此浪费的资源和浪费的内存一样多。