在C或c++应用程序中出现内存泄漏是可以接受的吗?
如果分配一些内存并一直使用到应用程序中的最后一行代码(例如,全局对象的析构函数),会怎样?只要内存消耗不随时间增长,那么当应用程序终止时(在Windows、Mac和Linux上),是否可以信任操作系统为您释放内存?如果内存一直被使用,直到被操作系统释放,您会认为这是真正的内存泄漏吗?
如果是第三方库将这种情况强加给您,该怎么办?会拒绝使用第三方库,不管它有多好?
我只看到了一个实际的缺点,那就是这些良性泄漏将在内存泄漏检测工具中显示为误报。
随着时间的推移,我看到的“良性”泄漏的数量一只手就能数得过来。
所以我的答案是肯定的。
An example. If you have a singleton resource that needs a buffer to store a circular queue or deque but doesn't know how big the buffer will need to be and can't afford the overhead of locking or every reader, then allocating an exponentially doubling buffer but not freeing the old ones will leak a bounded amount of memory per queue/deque. The benefit for these is they speed up every access dramatically and can change the asymptotics of multiprocessor solutions by never risking contention for a lock.
我已经看到这种方法在具有非常明确的固定计数的事情上有很大的好处,例如每cpu工作窃取deques,并且在Hans Boehm的C/ c++保守垃圾收集器中用于保存单例/proc/self/maps状态的缓冲区中有较小的程度,用于检测根集等。
虽然从技术上讲这是一个漏洞,但这两种情况在大小上都是有限制的,并且在可增长的循环工作窃取deque情况下,可以获得巨大的性能优势,以换取队列内存使用量增加2的有界因子。
首先,让我们把定义更正一下。内存泄漏是指动态分配内存,例如使用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;
}
你分配内存,使用它直到程序结束。这不是内存泄漏;它不会损害程序,并且当程序终止时,所有的内存将被自动清除。
一般来说,应该避免内存泄漏。首先,因为就像你头顶上的高度和飞机库里的燃料一样,已经泄漏且无法恢复的内存是无用的;其次,在一开始就正确编码,不泄漏内存,比后来发现内存泄漏要容易得多。