我们都被教导必须释放每个已分配的指针。不过,我有点好奇不释放内存的真正代价。在一些明显的情况下,比如在循环内部或线程执行的一部分调用malloc()时,释放是非常重要的,这样就不会有内存泄漏。但是考虑下面两个例子:

首先,如果我有这样的代码:

int main()
{
    char *a = malloc(1024);
    /* Do some arbitrary stuff with 'a' (no alloc functions) */
    return 0;
}

真正的结果是什么?我的想法是进程死亡,然后堆空间也消失了,所以错过对free的调用没有什么坏处(然而,我确实认识到无论如何拥有它对于闭包、可维护性和良好实践的重要性)。我这样想对吗?

Second, let's say I have a program that acts a bit like a shell. Users can declare variables like aaa = 123 and those are stored in some dynamic data structure for later use. Clearly, it seems obvious that you'd use some solution that will calls some *alloc function (hashmap, linked list, something like that). For this kind of program, it doesn't make sense to ever free after calling malloc because these variables must be present at all times during the program's execution and there's no good way (that I can see) to implement this with statically allocated space. Is it bad design to have a bunch of memory that's allocated but only freed as part of the process ending? If so, what's the alternative?


当前回答

如果您正在使用已分配的内存,那么您没有做错任何事情。当你编写的函数(main以外的)分配内存而不释放它,并且没有使它对程序的其余部分可用时,这就会成为一个问题。然后您的程序继续运行分配给它的内存,但没有办法使用它。您的程序和其他正在运行的程序将被剥夺该内存。

编辑:说其他正在运行的程序被剥夺了该内存并不是100%准确。操作系统总是可以让他们使用它,代价是把你的程序交换到虚拟内存(</ hand招手>)。关键是,如果您的程序释放了它不使用的内存,那么虚拟内存交换就不太可能是必要的。

其他回答

在OSTEP操作系统本科课程的在线教科书中,有一个章节恰好讨论了你的问题。

相关的章节是在第6页的内存API章节中“忘记释放内存”,给出了如下解释:

在某些情况下,不调用free()似乎是合理的。为 例如,你的程序是短命的,很快就会退出;在这种情况下, 当进程死亡时,操作系统将清理它分配的所有页面 因此,内存泄漏本身不会发生。虽然这当然“有效” (见第7页的旁白),这可能是一个坏习惯,所以要警惕 选择这样的策略

这段摘录是在介绍虚拟内存概念的上下文中。基本上,在本书的这一点上,作者解释了操作系统的目标之一是“虚拟化内存”,也就是说,让每个程序都相信它可以访问一个非常大的内存地址空间。

在幕后,操作系统会将用户看到的“虚拟地址”转换为指向物理内存的实际地址。

但是,共享物理内存等资源需要操作系统跟踪哪些进程正在使用它。因此,如果一个进程终止,那么在操作系统的能力和设计目标范围内回收该进程的内存,以便它可以重新分配并与其他进程共享内存。


编辑:节选中提到的旁白复制如下。

ASIDE: WHY NO MEMORY IS LEAKED ONCE YOUR PROCESS EXITS When you write a short-lived program, you might allocate some space using malloc(). The program runs and is about to complete: is there need to call free() a bunch of times just before exiting? While it seems wrong not to, no memory will be "lost" in any real sense. The reason is simple: there are really two levels of memory management in the system. The first level of memory management is performed by the OS, which hands out memory to processes when they run, and takes it back when processes exit (or otherwise die). The second level of management is within each process, for example within the heap when you call malloc() and free(). Even if you fail to call free() (and thus leak memory in the heap), the operating system will reclaim all the memory of the process (including those pages for code, stack, and, as relevant here, heap) when the program is finished running. No matter what the state of your heap in your address space, the OS takes back all of those pages when the process dies, thus ensuring that no memory is lost despite the fact that you didn’t free it. Thus, for short-lived programs, leaking memory often does not cause any operational problems (though it may be considered poor form). When you write a long-running server (such as a web server or database management system, which never exit), leaked memory is a much bigger issue, and will eventually lead to a crash when the application runs out of memory. And of course, leaking memory is an even larger issue inside one particular program: the operating system itself. Showing us once again: those who write the kernel code have the toughest job of all... from Page 7 of Memory API chapter of Operating Systems: Three Easy Pieces Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau Arpaci-Dusseau Books March, 2015 (Version 0.90)

如果一个程序在退出前忘记释放几兆字节,操作系统将释放它们。但是如果你的程序一次运行几个星期,并且程序内部的循环忘记在每次迭代中释放几个字节,你将会有一个巨大的内存泄漏,它将耗尽你计算机中所有可用的内存,除非你定期重新启动它=>如果程序用于一个非常大的任务,即使很小的内存泄漏也可能是不好的,即使它最初并不是为它设计的。

真正的结果是什么?

你的程序泄露了内存。根据您的操作系统,它可能已经恢复。

大多数现代桌面操作系统确实会在进程终止时恢复泄漏的内存,这使得忽略这个问题变得很常见(从这里可以看到许多其他答案)。

但是您依赖的是一个不属于该语言的安全特性,您不应该依赖它。您的代码可能运行在这样一个系统上,该行为下次会导致“硬”内存泄漏。

你的代码最终可能会在内核模式下运行,或者在老式/嵌入式操作系统上运行,这些操作系统不采用内存保护作为权衡。(mmu占用芯片空间,内存保护成本额外的CPU周期,并且要求程序员自己清理并不过分)。

您可以以任何您喜欢的方式使用和重用内存(和其他资源),但请确保在退出之前释放了所有资源。

如果您正在使用已分配的内存,那么您没有做错任何事情。当你编写的函数(main以外的)分配内存而不释放它,并且没有使它对程序的其余部分可用时,这就会成为一个问题。然后您的程序继续运行分配给它的内存,但没有办法使用它。您的程序和其他正在运行的程序将被剥夺该内存。

编辑:说其他正在运行的程序被剥夺了该内存并不是100%准确。操作系统总是可以让他们使用它,代价是把你的程序交换到虚拟内存(</ hand招手>)。关键是,如果您的程序释放了它不使用的内存,那么虚拟内存交换就不太可能是必要的。

不释放变量并没有真正的危险,但是如果将一个内存块的指针分配给另一个内存块而不释放第一个块,第一个块将不再可访问,但仍然占用空间。这就是所谓的内存泄漏,如果您经常这样做,那么您的进程将开始消耗越来越多的内存,从其他进程占用系统资源。

如果进程是短期的,那么通常可以这样做,因为当进程完成时,所有分配的内存都会被操作系统回收,但我建议养成释放所有不再使用的内存的习惯。