我们都被教导必须释放每个已分配的指针。不过,我有点好奇不释放内存的真正代价。在一些明显的情况下,比如在循环内部或线程执行的一部分调用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?


当前回答

如果您正在从头开始开发一个应用程序,那么您可以在何时调用free方面做出一些明智的选择。您的示例程序很好:它分配内存,也许您让它工作几秒钟,然后关闭,释放它所要求的所有资源。

但是,如果您正在编写其他任何东西——服务器/长时间运行的应用程序,或供其他人使用的库,则应该期望对malloc的所有内容调用free。

暂时忽略实用主义的一面,遵循更严格的方法,并强迫自己释放您malloc的所有内容要安全得多。如果您没有在编写代码时监视内存泄漏的习惯,那么很容易就会出现一些内存泄漏。换句话说,是的,你可以没有它;不过,请小心。

其他回答

退出时不释放内存是完全没问题的;Malloc()从称为“堆”的内存区域分配内存,当进程退出时释放整个堆。

也就是说,人们仍然坚持在退出前释放所有东西的一个原因是,内存调试器(例如Linux上的valgrind)将未释放的块检测为内存泄漏,如果你也有“真正的”内存泄漏,如果你在最后得到“假的”结果,那么发现它们会变得更加困难。

是的,你是对的,你的例子没有造成任何伤害(至少在大多数现代操作系统上没有)。进程退出后,操作系统将恢复进程分配的所有内存。

来源:分配和GC神话(PostScript警告!)

Allocation Myth 4: Non-garbage-collected programs should always deallocate all memory they allocate. The Truth: Omitted deallocations in frequently executed code cause growing leaks. They are rarely acceptable. but Programs that retain most allocated memory until program exit often perform better without any intervening deallocation. Malloc is much easier to implement if there is no free. In most cases, deallocating memory just before program exit is pointless. The OS will reclaim it anyway. Free will touch and page in the dead objects; the OS won't. Consequence: Be careful with "leak detectors" that count allocations. Some "leaks" are good!

也就是说,您应该尽量避免所有内存泄漏!

第二个问题:你的设计还可以。如果你需要存储一些东西直到你的应用程序退出,那么使用动态内存分配是可以的。如果您事先不知道所需的大小,就不能使用静态分配的内存。

为这个进程分配的所有内存将被OS标记为未使用,然后重用,因为内存分配是由用户空间函数完成的。

想象OS是一个上帝,而记忆是创造一个过程世界的材料,上帝用一些材料创造了一个世界(或者说OS保留了一些内存并在其中创造了一个过程)。无论这个世界上的生物做了什么,不属于这个世界的物质都不会受到影响。在这个世界过期后,OS神,可以回收分配给这个世界的材料。

现代操作系统在释放用户空间内存方面可能有不同的细节,但这必须是操作系统的基本职责。

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

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

===将来的校对和代码重用怎么办?= = =

如果你不编写释放对象的代码,那么你就将代码限制为只有当你可以依赖于进程关闭释放内存时才能安全使用……例如,小型一次性使用项目或“一次性”[1]项目)……你知道这个过程什么时候结束。

如果您确实编写了free()释放所有动态分配内存的代码,那么您就可以在未来验证代码,并让其他人在更大的项目中使用它。


[1]关于“一次性”项目。在“一次性”项目中使用的代码有一种不被丢弃的方法。接下来,十年过去了,你的“一次性”代码仍在使用)。

我听说过一个故事,说有个人写了一些代码,只是为了让他的硬件工作得更好。他说“只是一个爱好,不会有大的和专业的”。多年后,很多人都在使用他的“爱好”代码。