【发布时间】:2012-09-24 18:41:16
【问题描述】:
进程在某些操作系统上成功或异常终止,操作系统何时决定清除分配给该进程的内存(数据、代码等);在退出时或当它想要为新进程分配内存时?
这种清除内存分配的过程在所有操作系统(winXP、Win7、linux、Mac)上都是一样的吗?
我了解,页表映射了该进程的虚拟地址和内存中的实际物理地址。
谢谢。
【问题讨论】:
标签: windows linux memory memory-management
进程在某些操作系统上成功或异常终止,操作系统何时决定清除分配给该进程的内存(数据、代码等);在退出时或当它想要为新进程分配内存时?
这种清除内存分配的过程在所有操作系统(winXP、Win7、linux、Mac)上都是一样的吗?
我了解,页表映射了该进程的虚拟地址和内存中的实际物理地址。
谢谢。
【问题讨论】:
标签: windows linux memory memory-management
操作系统如何回收进程资源可能(并且通常会)因操作系统而异。在 Windows 方面,源自 NT 的操作系统的行为相似,因此 win XP 和 win7 之间应该没有什么区别。请注意,在这种情况下询问“记忆”是一种过度简化,因为有不同类型的记忆。例如,典型的 Windows 应用程序将具有堆栈内存、堆内存(有时是多个堆)、指令/静态内存,也许还有共享内存。大部分内存由进程单独拥有,Windows 将在进程终止(甚至异常终止)时回收它。
但是,共享内存可以(并且经常)有多个所有者;它与Windows handle(可能被多个进程引用的内核级对象)绑定。句柄有一个引用计数,如果引用计数变为零,相关的资源就会被回收。这意味着共享内存可以比引用它的进程寿命更长。此外,进程可能会“泄漏”句柄,并且该句柄永远不会被回收。确保此类句柄正确关闭且不泄漏是程序员的责任;异常终止的可能性使这一责任复杂化。
附带说明,当 Windows '回收'内存时,它只是意味着内存可用于将来分配给其他进程等。实际的 1 和 0 通常会坐在那里,直到操作系统分配内存 并且内存的新所有者主动覆盖它。所以“回收”并不意味着内存立即清零或类似的东西;在这件事上擦洗内存效率低下,而且通常是不必要的。如果您出于安全考虑而询问,则不应依赖操作系统;在进程将内存释放回操作系统之前,您需要自己清理内存。
如果您想了解更多关于现代 Windows 操作系统如何处理内存的信息,并且不介意进行一些挖掘,MSDN 上的 Windows API 文档有很多关于该主题的信息,但它有点分散。开始的好地方可能是 Windows 句柄和加载/卸载库/进程调用。 Application Programming for Windows (Richter) 可能有这方面的一些不错的信息,如果我没记错的话,但是我现在手头上没有副本可以检查。
希望对 Linux 内部知识更了解的人可以解决这个问题。这是特定于操作系统的东西,因此可能存在差异。值得注意的是,NT 之前的 Windows(例如 Windows 95、98 等)具有完全不同的进程内存模型。这些差异往往使操作系统在异常终止的情况下更难回收内存;一些用户发现如果他们运行不稳定的应用程序需要经常重启操作系统,以清理累积的内存泄漏。
【讨论】:
在 Linux 中,资源通常在进程终止时被释放。您可以在此处阅读有关 Linux 如何处理进程终止的信息:http://www.informit.com/articles/article.aspx?p=370047&seqNum=4
还有一个 OOM 杀手,它可以在内存极低的情况下启动.
【讨论】: