规则很简单:如果你用完了一些内存，就清理它。 有时，即使我们稍后需要一些实例，但我们注意到我们会大量使用内存，所以它会影响性能，因为交换到磁盘，我们可以将数据存储到磁盘文件中，然后重新加载它们，有时这种技术会优化你的程序。

No.

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

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

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

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

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

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

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

–

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

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

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

即使您确定“已知的”内存泄漏不会造成严重破坏，也不要这样做。在最好的情况下，它会为你在不同的时间和地点犯下类似的、可能更严重的错误铺平道路。

对我来说，问这个问题就像问“我可以在凌晨3点没有人的时候闯红灯吗?”当然，在那个时候它可能不会造成任何麻烦，但它将为你在高峰时间做同样的事情提供一个杠杆!

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

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

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

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

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