内存泄漏是否正常？
在C或C ++应用程序中发生内存泄漏是否可以接受？
如果你分配了一些内存并使用它直到应用程序中最后一行代码（例如全局对象的析构函数）呢？ 只要内存消耗不会随着时间增长，在应用程序终止时（Windows，Mac和Linux），信任操作系统为您释放内存是否可行？ 如果内存被连续使用直到被操作系统释放，你会否认为这是真正的内存泄漏？
如果第三方图书馆强迫你这样做，会怎么样？ 不管它有多么伟大，它会拒绝使用第三方库吗？
我只看到一个实际的缺点，那就是这些良性泄漏会以内存泄漏检测工具显示为误报。
没有。
作为专业人士，我们不应该问自己的问题是，“这样做可以吗？” 而是“有没有这样做的好理由？” 而“寻找内存泄漏是一种痛苦”并不是一个好的理由。
我喜欢保持简单。 简单的规则是我的程序应该没有内存泄漏。
这也让我的生活变得简单。 如果我检测到内存泄漏，我将其删除，而不是通过一些精心设计的决策树结构来确定它是否是“可接受的”内存泄漏。
它与编译器警告类似 - 警告是否会对我的特定应用程序致命？ 也许不会。
但它最终是一个专业纪律问题。 容忍编译器警告和容忍内存泄漏是一个坏习惯，最终会让我陷入后面。
为了让事情变得极端，外科医生是否可以将一些操作设备留在患者体内？
尽管可能会出现这样的情况：移除该设备的成本/风险超过了成本/风险，并且可能存在无害的情况，如果我在SurgeonOverflow.com上发布此问题看到除“不”之外的任何答案，这会严重破坏我对医学界的信心。
-
如果第三方图书馆强迫我这样做，这会使我严重怀疑图书馆的整体质量。 这就好像我测试驾驶汽车并在其中一个杯架中发现了一些松动的垫圈和螺母 - 它本身可能不是什么大不了的事，但它描绘了对质量的承诺，所以我会考虑替代品。
我不认为这是内存泄漏，除非内存被“使用”的数量不断增长。 拥有一些未释放的内存虽然不理想，但除非所需的内存量不断增长，否则这不是一个大问题。
首先让我们定义正确的。 内存泄漏是当内存被动态分配时，例如使用malloc() ，并且所有对内存的引用在没有相应的空闲时都会丢失。 一个简单的方法就是这样：
#define BLK ((size_t)1024)
while(1){
void * vp = malloc(BLK);
}
请注意，while（1）循环中每次都会分配1024（+开销）字节，并将新地址分配给vp; 没有剩下的指针指向以前的malloc'ed块。 该程序保证运行直到堆耗尽，并且无法恢复任何malloc分配的内存。 记忆从堆中“泄漏”出来，永远不会再被看到。
尽管如此，你所描述的听起来像
int main(){
void * vp = malloc(LOTS);
// Go do something useful
return 0;
}
你分配内存，使用它直到程序终止。 这不是内存泄漏; 它不会影响程序，并且程序终止时所有内存都将自动清除。
一般来说，你应该避免内存泄漏。 首先，因为像你身上的高空并在机库回油，泄漏和无法恢复的记忆是无用的; 其次，在开始的时候，正确编写代码要容易得多，而不是泄漏内存，而不是稍后发现内存泄漏。
链接地址: http://www.djcxy.com/p/3353.html