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

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

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

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


当前回答

我想你已经回答了自己的问题。最大的缺点是它们如何干扰内存泄漏检测工具,但我认为这个缺点对于某些类型的应用程序来说是一个巨大的缺点。

我使用的遗留服务器应用程序应该是坚如磐石的,但它们有泄漏,并且全局变量确实妨碍了内存检测工具。这是件大事。

在杰瑞德·戴蒙德(Jared Diamond)的《崩塌》(Collapse)一书中,作者想知道那个人在想什么,他砍倒了复活节岛上的最后一棵树,而这棵树是他建造独木舟离开该岛所需要的。我想知道许多年前第一个全局变量被添加到我们的代码库的那一天。那是它应该被抓住的日子。

其他回答

这实际上取决于创建内存泄漏的对象的使用情况。 如果在使用该对象的应用程序的生命周期内多次创建该对象,那么使用这种方式是不好的。因为会有很多内存泄漏。 另一方面,如果我们有一个对象的实例,不消耗内存,只泄漏少量,那么这不是一个问题。

当应用程序运行时内存泄漏增加时,内存泄漏就是一个问题。

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

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

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

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

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

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

不,你不应该有漏洞,操作系统会为你清理。原因(据我所知,在上面的答案中没有提到)是你永远不知道什么时候你的main()会在另一个程序中作为函数/模块被重用。如果你的main()在其他人的软件中经常被调用,那么这个软件就会有内存泄漏,随着时间的推移会消耗内存。

KIV