在C或c++应用程序中出现内存泄漏是可以接受的吗?

如果分配一些内存并一直使用到应用程序中的最后一行代码(例如,全局对象的析构函数),会怎样?只要内存消耗不随时间增长,那么当应用程序终止时(在Windows、Mac和Linux上),是否可以信任操作系统为您释放内存?如果内存一直被使用,直到被操作系统释放,您会认为这是真正的内存泄漏吗?

如果是第三方库将这种情况强加给您,该怎么办?会拒绝使用第三方库,不管它有多好?

我只看到了一个实际的缺点,那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。


当前回答

No.

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

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

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

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

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

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

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

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

其他回答

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

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

退出应用程序的好处是:

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

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

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

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

除非“使用”的内存量不断增长,否则我不认为这是内存泄漏。有一些未释放的内存,虽然不是理想的,但不是一个大问题,除非所需的内存数量不断增长。

我看到了和所有场景问题一样的问题,比如:当程序改变时,会发生什么?突然,这个小内存泄漏被调用了1000万次,而程序的结尾在不同的地方,所以它很重要?如果它在库中,那么请向库维护者记录错误,不要在您自己的代码中泄漏。

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

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

我想,如果你正在编写一个打算泄漏内存的程序(即测试内存泄漏对系统性能的影响),这是没有问题的。