当你在程序终止前没有释放malloc后，到底会发生什么?

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

当前回答

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

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

2009-03-17 15:33:02

其他回答

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

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

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

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

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

2009-03-17 16:43:37

几乎每个现代操作系统都会在程序退出后恢复所有已分配的内存空间。我能想到的唯一例外可能是像Palm OS这样的东西，其中程序的静态存储和运行时内存几乎是一样的，所以不释放可能会导致程序占用更多的存储空间。(我只是在猜测。)

所以一般来说，这样做没有什么坏处，除了存储容量超过所需的运行时成本。当然，在您给出的示例中，您希望保留可能被使用的变量的内存，直到它被清除。

然而，一旦你不再需要内存，就立即释放内存，并在程序退出时释放你仍然拥有的内存，这被认为是一种很好的方式。它更像是一种了解您正在使用哪些内存的练习，并考虑是否仍然需要它。如果不进行跟踪，可能会出现内存泄漏。

On the other hand, the similar admonition to close your files on exit has a much more concrete result - if you don't, the data you wrote to them might not get flushed, or if they're a temp file, they might not get deleted when you're done. Also, database handles should have their transactions committed and then closed when you're done with them. Similarly, if you're using an object oriented language like C++ or Objective C, not freeing an object when you're done with it will mean the destructor will never get called, and any resources the class is responsible might not get cleaned up.

2009-03-17 15:32:32

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

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

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

2009-03-17 15:35:35

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

2009-03-17 15:33:02

真正的结果是什么?

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

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

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

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