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

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

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

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


当前回答

首先,让我们把定义更正一下。内存泄漏是指动态分配内存,例如使用malloc(),并且所有对内存的引用都在没有相应的free的情况下丢失。制作一个简单的方法是这样的:

#define BLK ((size_t)1024)
while(1){
    void * vp = malloc(BLK);
}

注意,每次在while(1)循环中,分配1024(+开销)字节,并将新地址分配给vp;没有指向之前malloc 'Ed块的剩余指针。这个程序保证运行到堆用完为止,并且没有办法恢复任何malloc'ed内存。内存从堆中“泄漏”出来,再也看不见了。

你所描述的,听起来就像

int main(){
    void * vp = malloc(LOTS);
    // Go do something useful
    return 0;
}

你分配内存,使用它直到程序结束。这不是内存泄漏;它不会损害程序,并且当程序终止时,所有的内存将被自动清除。

一般来说,应该避免内存泄漏。首先,因为就像你头顶上的高度和飞机库里的燃料一样,已经泄漏且无法恢复的内存是无用的;其次,在一开始就正确编码,不泄漏内存,比后来发现内存泄漏要容易得多。

其他回答

如果分配内存并一直使用到程序的最后一行,这就不是泄漏。如果您分配内存并忘记它,即使内存数量没有增长,这也是一个问题。已分配但未使用的内存可能导致其他程序运行速度变慢或根本不运行。

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

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

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

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

虽然大多数答案都集中在真正的内存泄漏(这是不正确的,因为它们是草率编码的标志),但这个问题的这一部分对我来说似乎更有趣:

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

如果使用了相关的内存,则在程序结束之前不能释放它。释放是由程序退出还是由操作系统完成并不重要。只要有文档记录,这样更改就不会引入真正的内存泄漏,并且在图中不涉及c++析构函数或C清理函数。未关闭的文件可能通过泄漏的file对象显示,但缺少fclose()也可能导致缓冲区不被刷新。

所以,回到最初的情况,在我看来,它本身是完全OK的,以至于Valgrind,最强大的泄漏探测器之一,只会在要求时处理此类泄漏。在Valgrind上,当您覆盖一个指针而没有事先释放它时,它会被认为是内存泄漏,因为它更有可能再次发生,并导致堆无休止地增长。

然后,就没有仍然可以访问的nfreed内存块了。我们可以确保在出口释放所有人,但这本身就是浪费时间。关键是他们之前能不能被释放。降低内存消耗在任何情况下都是有用的。

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

If I understood correctly, you don't explicitly free memory (which can be freed because you still have a pointer) and rely on OS to free it during process termination. Though this may seem okay for simple program, consider the situation where your code is moved into a library and becomes a part of some resident daemon process running 24/7. Say this daemon spawns a thread each time it needs to do something useful using your code and say it spawns thousands of threads every hour. In this case you will get real memory leak.

不幸的是,这种情况在现实生活中并非不可能,一致的内存管理技术可能会使您的生活更轻松。