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

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

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

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


当前回答

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

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

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

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

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

前甲板

其他回答

在程序的最后一行省略释放内存是完全可以接受的,因为释放它不会对任何事情产生影响,因为程序再也不需要内存了。

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

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

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

最佳实践是始终释放所分配的空间,特别是在编写旨在在整个系统正常运行期间运行的内容时,即使在退出之前进行清理。

这是一个非常简单的规则。以无泄漏为目标进行编程,可以很容易地发现新的泄漏。你会卖给别人一辆你自己造的车吗?你知道它一熄火就会喷到地上?:)

清理函数中的一些if () free()调用是廉价的,为什么不使用它们呢?

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

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

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

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