据我所知,每个进程都有自己的操作系统分配的地址空间。因此,当程序终止时,整个地址空间被标记为无效(或可以再次重复使用)。现在,如果上述进程泄漏内存,程序终止后会有什么不同吗?
也就是说,如果我的程序在某个时间后终止或者以连续的启动完成机制以短时间间隔运行,那么泄漏的内存会有多大差异? (我假设泄漏不足以引起普通系统的颠簸)
我知道泄漏很糟糕 - 但我的问题源于假设在代码的最后一个例程中使用了一个对象 - 不会修复泄漏会产生任何差异,因为此过程将在此之后终止?
先谢谢:)
答案 0 :(得分:1)
这是一个非常依赖操作系统的问题。
在使用虚拟内存的现代多处理操作系统(例如:Windows 7,Linux)中,确实所有(好的,不是所有,但让我们在这里不挑剔)资源是特定于流程,并在流程终止时将其释放回系统。
如果您的程序“泄漏内存”,那么重要吗?那么,这取决于它是如何做到的。
如果你在启动时分配了一堆资源,那么如果你在关机时手动释放它们或者只是让操作系统执行它就没关系。我承认自己是一个懒惰的程序员,喜欢让操作系统处理这些事情。
但是,如果你出于某种原因在循环中或在运行时按需分配资源,并且不想以某种方式管理它们,那么从理论上讲,如果你让你的程序运行得足够长,它将不断地“泄漏”资源直到有一点为止,没有任何剩余要分配。这是 Bad Thing 。不要这样做。
现在有很多平台没有这种方式。如果你最终做了嵌入式工作,你很可能最终会在一个平台上,你必须管理你自己的所有资源(手动释放内存,关闭文件句柄等)。
答案 1 :(得分:0)
在具有独立内核和用户空间的现代操作系统和内存管理器中,每个用户进程只能看到虚拟内存(正如您所说),通常情况下,任何给定的用户进程通常都不可能损害操作系统(不包括当然,特权用户故意搞乱系统内存。这就是多进程多任务操作系统的全部概念:操作系统拥有许多同时进行托管的进程,而不必依赖于协作的进程。
(也就是说,如果内存泄漏是由于无效的访问错误造成的,那么您仍然容易受到代码注入的影响,这可能会因系统其他部分的权限提升漏洞而进一步加剧,因此进程的隔离只会如此远。)
答案 2 :(得分:0)
如果您只是抓住了比实际需要的更多的堆,那么当进程退出时它将被回收。
我不清楚你是怎么知道你在这种情况下泄漏记忆的,但假设你确实这样做了,那么你仍然应该解决它。这是你代码中的定时炸弹。
两个原因的例子:
您可能遇到可扩展性问题:
for(某些事情清单) 做一些泄漏100字节的工作
现在你迭代10次,泄漏1000个字节,终止,没什么大不了的。在未来,您需要进行10,000次交互,并且由于内存不足而导致必要的关闭工作失败......