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

来源:分配和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!

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

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

几乎每个现代操作系统都会在程序退出后恢复所有已分配的内存空间。我能想到的唯一例外可能是像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.

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

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

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

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

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

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

您是正确的，当进程退出时，内存将自动释放。有些人在进程终止时尽量不进行广泛的清理，因为它将全部移交给操作系统。然而，当你的程序运行时，你应该释放未使用的内存。如果不这样做，如果您的工作集太大，最终可能会耗尽或导致过度分页。

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

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

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

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

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

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

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

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

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

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

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

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

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

这段代码通常可以正常工作，但是要考虑代码重用的问题。

你可能写了一些没有释放分配内存的代码片段，它以这样一种方式运行，然后自动回收内存。似乎还好吧。

然后另一个人将您的代码片段复制到他的项目中，以每秒执行1000次的方式。这个人现在在他的程序中有一个巨大的内存泄漏。一般来说不是很好，对于服务器应用程序来说通常是致命的。

代码重用在企业中很常见。通常公司拥有其员工生产的所有代码，每个部门都可以重用公司拥有的任何代码。因此，通过编写这种“看起来很无辜”的代码，您可能会给其他人带来潜在的麻烦。这可能会让你被炒鱿鱼。

一旦我确定我已经完成了每个分配的块，我通常会释放它。今天，我的程序的入口点可能是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”:)

你说得对，不会造成伤害，直接退出会更快

原因有很多:

All desktop and server environments simply release the entire memory space on exit(). They are unaware of program-internal data structures such as heaps. Almost all free() implementations do not ever return memory to the operating system anyway. More importantly, it's a waste of time when done right before exit(). At exit, memory pages and swap space are simply released. By contrast, a series of free() calls will burn CPU time and can result in disk paging operations, cache misses, and cache evictions.

关于未来代码重用的可能性，为毫无意义的操作的确定性辩护:这是一个考虑，但可以说这不是敏捷的方式。YAGNI !

我完全不同意那些说OP是正确的或没有伤害的人。

每个人都在谈论现代和/或传统的操作系统。

但是如果我在一个没有操作系统的环境中呢? 哪里什么都没有?

想象一下，现在您正在使用线程样式的中断并分配内存。 在C标准ISO/IEC:9899中，内存的寿命表示为:

7.20.3 Memory management functions 1 The order and contiguity of storage allocated by successive calls to the calloc, malloc, and realloc functions is unspecified. The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated). The lifetime of an allocated object extends from the allocation until the deallocation.[...]

所以我们不能认为环境在为你做释放的工作。 否则，它将被添加到最后一句:“或直到程序终止。”

换句话说: 不释放内存不仅仅是不好的做法。它生成不可移植且不符合C的代码。 至少可以被视为“正确的”，如果有以下情况:[…]]，由environment支持。

但如果你根本就没有操作系统，那就没有人在为你做这项工作了 (我知道通常在嵌入式系统中不会分配和重新分配内存， 但在某些情况下，你可能想这么做。)

在普通的C语言中(OP被标记) 这只会产生错误的和不可移植的代码。

真正的结果是什么?

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

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

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

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

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

在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)

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

这取决于你正在做的项目的范围。在你的问题的背景下，我是说仅仅是你的问题，那就不重要了。

为了进一步解释(可选)，我从整个讨论中注意到的一些场景如下:

(1) -如果你在一个嵌入式环境中工作，你不能依靠主操作系统来回收内存，那么你应该释放它们，因为如果不注意的话，内存泄漏真的会使程序崩溃。

(2) -如果你正在做一个个人项目，你不会向任何人透露它，那么你可以跳过它(假设你在主操作系统上使用它)，或者出于“最佳实践”的考虑而包含它。

(3) -如果你正在开发一个项目，并计划让它开源，那么你需要对你的受众做更多的研究，并弄清楚释放内存是否是更好的选择。

(4)如果你有一个很大的库，而你的用户只有主操作系统，那么你就不需要释放它，因为他们的操作系统会帮助他们这么做。同时，通过不释放，你的库/程序可能有助于提高整体性能，因为程序不需要关闭每个数据结构，延长关机时间(想象一下，在离开家之前，你要非常缓慢地等待关机……)

我可以继续指定要采取哪一种方法，但这最终取决于您想用程序实现什么。释放内存在某些情况下被认为是很好的实践，但在某些情况下则不是，因此它最终取决于您所处的具体情况，以及在正确的时间提出正确的问题。好运！

It depends on the OS environment the program is running in, as others have already noted, and for long running processes, freeing memory and avoiding even very slow leaks is important always. But if the operating system deals with stuff, as Unix has done for example since probably forever, then you don't need to free memory, nor close files (the kernel closes all open file descriptors when a process exits.) If your program allocates a lot of memory, it may even be beneficial to exit without "hesitation". I find that when I quit Firefox, it spends several !minutes ! paging in gigabytes of memory in many processes. I guess this is due to having to call destructors on C++ objects. This is actually terrible. Some might argue, that this is necessary to save state consistently, but in my opinion, long-running interactive programs like browsers, editors and design programs, just to mention a few, should ensure that any state information, preferences, open windows/pages, documents etc is frequently written to permanent storage, to avoid loss of work in case of a crash. Then this state-saving can be performed again quickly when the user elects to quit, and when completed, the processes should just exit immediately.

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

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

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