我们都被教导必须释放每个已分配的指针。不过，我有点好奇不释放内存的真正代价。在一些明显的情况下，比如在循环内部或线程执行的一部分调用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?
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.
这取决于你正在做的项目的范围。在你的问题的背景下，我是说仅仅是你的问题，那就不重要了。
为了进一步解释(可选)，我从整个讨论中注意到的一些场景如下:
(1) -如果你在一个嵌入式环境中工作，你不能依靠主操作系统来回收内存，那么你应该释放它们，因为如果不注意的话，内存泄漏真的会使程序崩溃。
(2) -如果你正在做一个个人项目，你不会向任何人透露它，那么你可以跳过它(假设你在主操作系统上使用它)，或者出于“最佳实践”的考虑而包含它。
(3) -如果你正在开发一个项目，并计划让它开源，那么你需要对你的受众做更多的研究，并弄清楚释放内存是否是更好的选择。
(4)如果你有一个很大的库，而你的用户只有主操作系统，那么你就不需要释放它，因为他们的操作系统会帮助他们这么做。同时，通过不释放，你的库/程序可能有助于提高整体性能，因为程序不需要关闭每个数据结构，延长关机时间(想象一下，在离开家之前，你要非常缓慢地等待关机……)
我可以继续指定要采取哪一种方法，但这最终取决于您想用程序实现什么。释放内存在某些情况下被认为是很好的实践，但在某些情况下则不是，因此它最终取决于您所处的具体情况，以及在正确的时间提出正确的问题。好运！
几乎每个现代操作系统都会在程序退出后恢复所有已分配的内存空间。我能想到的唯一例外可能是像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.
你说得对，不会造成伤害，直接退出会更快
原因有很多:
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 !
