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

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

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

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


当前回答

Some great answers here. To add another perspective to this question, I'll address a case where memory leak is not only acceptable but desirable: in Windows drivers environment the developer provides a set of callbacks that are being run by the OS whenever required. One of the callbacks is a 'Shutdown' callback, which runs prior to system being shut off/restarted. Unlike standard situations, not only memory release is not necessary (system will be off in a moment), it's even discouraged - to make the shutdown as fast as possible and prevent the overhead of memory management.

其他回答

从历史上看,在某些边缘情况下,它在某些操作系统上确实很重要。这些边缘情况在未来可能会存在。

Here's an example, on SunOS in the Sun 3 era, there was an issue if a process used exec (or more traditionally fork and then exec), the subsequent new process would inherit the same memory footprint as the parent and it could not be shrunk. If a parent process allocated 1/2 gig of memory and didn't free it before calling exec, the child process would start using that same 1/2 gig (even though it wasn't allocated). This behavior was best exhibited by SunTools (their default windowing system), which was a memory hog. Every app that it spawned was created via fork/exec and inherited SunTools footprint, quickly filling up swap space.

我的回答是没有。

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

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

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

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

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

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

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

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

如果你在程序开始时分配了一堆内存,但退出时没有释放它,这本身并不是内存泄漏。内存泄漏是指当程序循环遍历一段代码时,该代码分配堆,然后在没有释放它的情况下“失去跟踪”。

事实上,在退出之前不需要调用free()或delete。当进程退出时,它的所有内存都被操作系统回收(POSIX当然就是这种情况。在其他操作系统上-特别是嵌入式的- YMMV)。

对于退出时不释放内存,我唯一要注意的是,如果你重构了你的程序,例如,它变成了一个等待输入的服务,做你的程序所做的任何事情,然后循环等待另一个服务调用,那么你所编写的代码可能会变成内存泄漏。