我们都被教导必须释放每个已分配的指针。不过，我有点好奇不释放内存的真正代价。在一些明显的情况下，比如在循环内部或线程执行的一部分调用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?
是的，你是对的，你的例子没有造成任何伤害(至少在大多数现代操作系统上没有)。进程退出后，操作系统将恢复进程分配的所有内存。
来源:分配和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!
也就是说，您应该尽量避免所有内存泄漏!
第二个问题:你的设计还可以。如果你需要存储一些东西直到你的应用程序退出，那么使用动态内存分配是可以的。如果您事先不知道所需的大小，就不能使用静态分配的内存。
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.
