C程序调用exit终止时是否需要主动释放已分配的内存？

在你说的malloc失败调用exit(1)退出的场景下，完全没必要手动释放之前申请的所有内存。所有现代通用操作系统（Linux、Windows、macOS、BSD系列）都会在进程终止时，由内核自动回收这个进程占有的全部内存、文件句柄、套接字等所有资源，根本不会留内存泄漏给系统。

• 纯做无用功：进程退出的时候，内核会直接把整个进程的地址空间、关联的物理内存页全部回收掉。你在用户态辛辛苦苦调用free把内存块还给C库的内存管理器，这些操作的结果转头就被内核的回收操作覆盖了，半毛钱实际价值都没有，只会拖慢程序退出速度。
• 反而容易出问题：malloc都返回NULL了，说明系统已经处于内存耗尽的边缘，这时候跑全局释放的逻辑，要遍历各种数据结构、层层指针访问，万一之前因为内存不足写坏了堆结构，很可能直接触发二次崩溃，连正常退出都做不到。
• 这本来就是行业通用做法：不管是Redis、Nginx还是SQLite这些经过几十年生产验证的C项目，遇到内存申请失败的致命错误，都是直接调exit()退，根本不会费劲去释放之前申请的所有内存。

别把上面的结论当成放之四海而皆准的真理，遇到下面的场景要按实际情况处理：

• 跑在没有进程资源回收机制的环境里：比如裸机程序、部分老旧的嵌入式RTOS，这类系统根本没有“进程退出自动回收资源”的设计，你申请的内存不手动释放，就会一直占着，跑久了整个系统内存都会被耗光，这种情况必须按规范释放。
• 调试阶段适配内存检测工具：如果你用Valgrind、ASAN这类工具查内存问题，不释放的内存会被工具标成泄漏点，为了拿到干净的检测报告，你可以在调试版本里加退出时的释放逻辑，但这只是为了方便调试，生产环境完全不需要这么做。
• 有数据要落盘：如果内存里存着没写到磁盘的关键数据，比如用户操作日志、未保存的配置，那你要在退出前把这些数据刷到磁盘上，但这是为了保证数据不丢，和释放内存是两码事，别搞混了。

很多人张口就说“写C必须申请了就释放，不释放就是不规范”，这话只对程序正常运行的阶段有效：比如你处理一个请求申请了临时内存，请求处理完就要释放，不然跑着跑着内存就涨满了。但进程都要退出了，整个内存都要被系统收走，这时候还逐块去free，就是纯粹的教条主义，没有任何实际意义。

内容的提问来源于stack exchange，提问作者ishaangupte