内存泄漏还好吗？

Question

在您的C或C++应用程序中有一个C++是否可以接受？

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

如果第三方库把这种情况强加给你呢？会拒绝使用那个第三方库，不管它在其他方面有多大？

我只看到一个实际的缺点，那就是这些良性泄漏将以错误的形式出现在内存泄漏检测工具中。

Answer 1

不是的。

作为专业人士，我们不应该问自己的问题是：“这样做可以吗？”但是更确切地说，“有一个好的理由去做这件事吗？”“寻找记忆泄漏是一种痛苦”并不是一个好的理由。

我喜欢保持简单。简单的规则是我的程序不应该有内存泄漏。

我的生活也很简单。如果我检测到内存泄漏，我就消除它，而不是运行一些复杂的决策树结构来确定它是否是“可接受的”内存泄漏。

它类似于编译器警告--对我的特定应用程序来说，警告会是致命的吗？也许不是。

但这最终还是一个专业纪律的问题。容忍编译器警告和容忍内存泄漏是一个坏习惯，最终会咬我的后腿。

要把事情搞到极致，外科医生把手术设备留在病人体内是可以接受的吗？

虽然移除该设备的成本/风险可能超过留在该设备的成本/风险，而且有些情况是无害的，但如果我在SurgeonOverflow.com上看到这个问题，并看到“否”以外的任何答案，这将严重损害我对医学界的信心。

-

如果第三方图书馆把这种情况强加给我，我就会对该图书馆的整体质量产生严重怀疑。这就好像我测试了一辆汽车，在其中一个保持架上发现了几个松动的垫圈和螺母--这本身可能不是什么大不了的事，但它描述了对质量的缺乏承诺，所以我会考虑其他选择。

Answer 2

我不认为这是内存泄漏，除非被“使用”的内存数量持续增长。拥有一些未释放的内存，虽然不理想，但不是一个大问题，除非需要的内存数量不断增长。

Answer 3

首先，让我们的定义正确。内存泄漏是指在动态分配内存(如使用malloc() )时，所有对内存的引用都会丢失，而没有相应的空闲。一个简单的方法是这样做：

#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;
}

您分配内存，使用它直到程序终止。这不是内存泄漏；它不会损害程序，当程序终止时，所有内存都会自动清除。

通常，您应该避免内存泄漏。首先，就像你上面的高度和机库里的燃料一样，泄漏的、无法恢复的内存是无用的；第二，在开始时正确编码，而不是内存泄漏，比后来发现内存泄漏要容易得多。