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


当前回答

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

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

其他回答

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

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

在那方面你完全正确。在小的程序中,变量必须存在,直到程序结束,释放内存并没有真正的好处。

事实上,我曾经参与过一个项目,在这个项目中,程序的每次执行都非常复杂,但时间相对较短,决定只是保持分配内存,而不是因为错误地释放内存而破坏项目的稳定。

话虽如此,在大多数程序中,这并不是一个真正的选项,或者它会导致内存耗尽。

一旦我确定我已经完成了每个分配的块,我通常会释放它。今天,我的程序的入口点可能是main(int argc, char *argv[]),但明天它可能是foo_entry_point(char **args, struct foo *f),并类型为函数指针。

所以,如果发生这种情况,我现在就有了漏洞。

关于你的第二个问题,如果我的程序输入a=5,我会为a分配空间,或者在后续的a="foo"上重新分配相同的空间。这笔款项将继续分配至:

用户输入'unset a' 我的清理功能被输入,要么服务一个信号,要么用户输入“退出”

我想不出有哪个现代操作系统在进程退出后不回收内存。free()很便宜,为什么不清理一下呢?正如其他人所说,像valgrind这样的工具对于发现您确实需要担心的泄漏非常有用。即使你示例中的块被标记为“仍然可达”,当你试图确保没有泄漏时,它只是输出中的额外噪音。

另一个误区是“如果它在main()中,我就不必释放它”,这是不正确的。考虑以下几点:

char *t;

for (i=0; i < 255; i++) {
    t = strdup(foo->name);
    let_strtok_eat_away_at(t);
}

如果这发生在fork / daemonizing(理论上永远运行)之前,那么您的程序已经泄漏了255次大小不确定的t。

一个好的,编写良好的程序应该总是自我清理。释放所有内存,刷新所有文件,关闭所有描述符,解除所有临时文件的链接等等。应该在正常终止或接收到各种致命信号时执行此清理功能,除非您想要保留一些文件以便检测崩溃并恢复。

真的,当你去做其他事情的时候,要善待那些不得不维护你的东西的可怜人。递给他们“valgrind clean”:)

我认为你的两个例子实际上只有一个:free()应该只在进程结束时发生,正如你指出的那样,这是无用的,因为进程正在终止。

但在第二个示例中,唯一的区别是允许未定义的malloc()数量,这可能导致内存耗尽。处理这种情况的唯一方法是检查malloc()的返回代码并采取相应的行动。

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

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

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


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

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