我同意vfilby -这要看情况。在Windows中，我们将内存泄漏视为相对严重的错误。但是，这很大程度上取决于分量。

例如，对于很少运行且运行时间有限的组件，内存泄漏不是很严重。这些组件运行，完成工作，然后退出。当它们退出时，所有内存都被隐式释放。

但是，服务或其他长期运行组件(如shell)中的内存泄漏非常严重。原因是这些bug会随着时间的推移“窃取”内存。恢复的唯一方法是重新启动组件。大多数人不知道如何重新启动服务或shell——所以如果他们的系统性能受到影响，他们就重新启动。

所以，如果你有一个泄漏-评估它的影响两种方式

你的软件和你的用户体验。 对于系统(和用户)来说，节省系统资源是非常重要的。 修复对维护和可靠性的影响。 在其他地方造成倒退的可能性。

前甲板

我的回答是没有。

从理论上讲，如果你把东西弄得乱七八糟，操作系统会帮你清理干净(这很粗鲁，但由于计算机没有感情，这可能是可以接受的)。但是，您无法预测程序运行时可能发生的每一种情况。因此(除非您能够对某些行为进行正式的证明)，从专业的角度来看，造成内存泄漏是不负责任和草率的。

如果第三方组件泄漏内存，这是一个非常强烈的反对使用它的理由，不仅因为即将发生的影响，而且因为它表明程序员工作草率，这也可能影响其他指标。现在，当考虑遗留系统时，这是困难的(考虑web浏览组件:据我所知，它们都泄漏内存)，但这应该是标准。

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

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

No.

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

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

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

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

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

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

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

–

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

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

如果一直使用到main()的尾部，则根本不是泄漏(当然，假设有受保护的内存系统!)

事实上，在进程关闭时释放对象绝对是你能做的最糟糕的事情……操作系统必须将你创建的每一页回退。关闭文件句柄，数据库连接，当然，但释放内存是愚蠢的。