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

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

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

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


当前回答

看来你对“内存泄漏”的定义是“我自己不清理的内存”。所有现代操作系统都会在程序退出时释放它。然而,由于这是一个c++问题,您可以简单地将所讨论的内存包装在适当的std::auto_ptr中,当它超出作用域时将调用delete。

其他回答

这个问题已经讨论得令人作呕了。最重要的是,内存泄漏是一个bug,必须修复。如果第三方库泄露了内存,就会让人怀疑它还有什么问题,不是吗?如果你要造一辆汽车,你会使用一个偶尔漏油的发动机吗?毕竟,引擎是别人做的,所以这不是你的错,你不能修,对吧?

我的回答是没有。

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

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

许多人似乎都有这样的印象:一旦释放内存,它就会立即返回到操作系统,可以被其他程序使用。

这不是真的。操作系统通常以4KiB页面管理内存。malloc和其他类型的内存管理从操作系统获取页面,并在它们认为合适的时候对它们进行子管理。free()很可能不会将页面返回给操作系统,前提是您的程序稍后会误用更多内存。

我并不是说free()从不将内存返回给操作系统。这是有可能发生的,特别是当您正在释放大量内存时。但这并不能保证。

重要的事实是:如果不释放不再需要的内存,那么进一步的malloc必然会消耗更多的内存。但是如果先释放,malloc可能会重新使用释放的内存。

这在实践中意味着什么?这意味着如果你知道你的程序从现在开始不再需要更多的内存(例如它在清理阶段),释放内存就不是那么重要了。但是,如果程序稍后可能分配更多内存,则应该避免内存泄漏——特别是那些可能重复发生的内存泄漏。

关于为什么在终止前释放内存是不好的,请参阅这条评论了解更多细节。

评论者似乎不理解调用free()并不会自动允许其他程序使用释放的内存。但这就是这个答案的全部意义!

因此,为了说服人们,我将演示一个例子,其中free()没有什么好处。为了便于计算,我假设操作系统以4000字节的页面管理内存。

Suppose you allocate ten thousand 100-byte blocks (for simplicity I'll ignore the extra memory that would be required to manage these allocations). This consumes 1MB, or 250 pages. If you then free 9000 of these blocks at random, you're left with just 1000 blocks - but they're scattered all over the place. Statistically, about 5 of the pages will be empty. The other 245 will each have at least one allocated block in them. That amounts to 980KB of memory, that cannot possibly be reclaimed by the operating system - even though you now only have 100KB allocated!

另一方面,您现在可以malloc() 9000多个块,而不会增加程序占用的内存量。

即使free()在技术上可以将内存返回给操作系统,它也可能不会这样做。Free()需要在快速操作和节省内存之间取得平衡。此外,一个已经分配了大量内存然后释放它的程序很可能会再次这样做。web服务器需要处理一个又一个的请求——保持一些“松弛”的可用内存是有意义的,这样你就不需要一直向操作系统请求内存了。

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

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

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

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

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

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

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