This question 让我很好奇。像这样的问题总是得到像“它通常是安全的，但你不应该假设操作系统会为你做这件事”的答案，这对我来说听起来是个好建议，但我想知道：是否有任何积极开发（已发布）不这样做的操作系统？
这是在恐龙时代（80 年代）修复的东西吗？
【问题讨论】：
标签： memory-management operating-system
简短的回答是“无”。即使是多年前 DOS 上的程序也会在程序终止时释放内存（仅仅因为程序停止时没有任何东西管理内存）。我敢肯定有人可能会看到内核模式代码不一定会在应用程序退出时释放其内存，或者他们可能会引用一些晦涩的嵌入式操作系统......但您可以假设 app-exit 返回您的用户模式代码获得的所有内存. （Windows 3.x 可能会遇到这个问题，具体取决于使用的分配器...）
你“应该释放你的记忆”的美德的原因是，对于大型软件工程，你应该努力开发使用灵活的组件，因为你永远不知道其他人将如何改变使用你离开团队很久之后的代码。
这样想。假设您设计了一些设计为单例的类（在应用程序生命周期内仅实例化一次）。因此，当您的组件销毁或完成时，您决定不打扰内存清理。在那一刻，这是一个非常好的决定。多年后，在您离开到更绿色的牧场后，其他人可能会出现并决定他们需要在多个地方使用您的类，这样在应用程序的生命周期中就会出现许多实例。您的内存泄漏将成为他们的问题。
在我的团队中，我们经常谈论让用户启动的应用程序“关闭”只是 exit() 而不进行任何清理。如果我们这样做了，我仍然会强制团队开发能够自行清理的类和组件。
【讨论】：
exit() 仍然会导致泄漏（因此不适合作为对“关闭”的响应）。有些非内存资源可能不会被操作系统清理（例如文件锁）。
当进程退出时，最近没有一个类似 unix 的操作系统无法释放所有进程内存，其中最近可能意味着“自 1970 年左右”。我相当确定 DOS 和 CP/M 等非常古老的 PC 操作系统以及一些旧版本的 Windows 都有这个问题。我对最近的 Windows 了解不多，无法确定，但如果 Windows XP、Vista 或 Windows 7 中的任何一个在释放进程内存时出现问题，我会感到非常惊讶。
根据经验，我建议任何不使用虚拟内存为进程提供单独地址空间的操作系统在进程发生重大故障时都可能容易出现内存泄漏。一旦操作系统实现了每个进程的虚拟地址空间，它就必须跟踪分配给进程的所有物理内存，因此可靠地释放它很简单。
综上所述，编写程序以自行清理通常是个好主意。它往往会导致设计更好的子组件，并且还可以更轻松地应用查找内存泄漏等的工具。
【讨论】：
在 CP/M 中，释放这么多内存不是问题，因为您的程序有一个静态 RAM 区域，并且每个程序都在同一个空间中运行。因此，当程序 A 退出，程序 B 运行时，B 只是简单地加载到 A 之上。
现在有一些机制可以从操作系统中保留内存，但这通常不是堆内存（在我们今天考虑的经典案例中），它是为各种任务设计的特殊保留区域。
例如，DOS 有一个名为“Terminate and Stay Resident”的退出例程。这“退出”了程序，但程序退出后并没有释放空间。通常，这些程序加载中断向量（例如键盘中断）来触发例程。 Borland Sidekick 在当时是一个非常受欢迎的“TSR”，提供计算器和联系人列表等功能。
最后，由于这些不是受保护的内存系统，您的程序可能会以各种方式滥用系统来做您想做的事情，但这是一个不同的讨论。
【讨论】：
int 21h(ah=4ch)、int 20h和int 21h(ah=0)执行int 21h(ah=48h)分配的空闲内存，不像“TSR”int 21h(ah=31h)那样t.