内存泄漏与操作系统
据我所知，每个进程都有自己的由操作系统分配的地址空间。因此，当程序终止时，整个地址空间被标记为无效（或者可以再次重用）。现在，如果上述进程正在泄漏内存，那么程序终止后会有什么影响吗？
也就是说，如果我的程序在一段时间后终止，或者以连续的开始-结束机制以短间隔运行，泄漏内存会有多大区别吗？ （我假设泄漏不够大，不足以在平均系统上引起抖动）
我知道泄漏很糟糕 - 但我的问题源于假设在代码的最终例程中使用对象的观点 - 不会修复泄漏有什么区别，因为无论如何，进程都会在此之后终止？
提前致谢 ：）
I understand that each process has its own address space allocated by the Operating System. So when the program terminates, that whole address space is marked as invalid (or is free to be reused again). Now if the said process is leaking memory, will it make any difference after the program is terminated ?
That is to say, if my program is terminated after sometime or is run at short intervals with continuous start-finish mechanism, will leaking memory make much difference ? (i am assuming the leak is not large enough to cause thrashing on an average system)
I know leaks are bad - but my question stems from the point that suppose an object is being used in the final routine of the code - will NOT FIXING the leak make any difference as the process is going to be terminated after this anyway ?
Thanks in Advance :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个非常依赖操作系统的问题。
在使用虚拟内存的现代多处理操作系统（例如：Windows 7、Linux）上，确实所有（好吧，不是全部，但我们不要在这里挑剔）资源都是特定于进程的并在进程终止时释放回系统。
那么你的程序是否“泄漏内存”有什么关系吗？嗯，这取决于它是如何做到的。
如果您在启动时分配了一堆资源，那么您在关闭时手动释放它们还是让操作系统来释放它们并不重要。我承认我是一个懒惰的程序员，喜欢让操作系统处理这些事情。
但是，如果您出于某种原因在循环中或在运行时按需分配资源，并且不费心以某种方式管理它们，那么理论上，如果您让程序运行足够长的时间，它将不断“泄漏”资源，直到达到这一点没有更多的剩余可分配了。这是一件坏事。不要这样做。
现在有很多平台不这样做。如果您最终从事嵌入式工作，那么您很可能最终会进入一个必须管理自己的所有资源（手动释放内存、关闭文件句柄等）的平台。
This is a very OS-dependent question.
On a modern multiprocessing OS that uses Virtual Memory (eg: Windows 7, Linux), it is true that all (OK, not all, but let's not be nit-picky here) resources are process-specific and will be released back to the system when the process terminates.
So does it matter if your program "leaks memory"? Well, that depends on how it does it.
If you allocate a bunch of resources at startup, no it does not really matter if you manually free them at shutdown or just let the OS do it. I'll admit to being a lazy programmer who likes to let the OS handle such things.
However, if you allocate resources in a loop or on demand at runtime for some reason, and don't bother to manage them in some way, then theoretically if you let your program run long enough it will continually "leak" resources until the point comes that there aren't any more left to allocate. This is a Bad Thing. Don't do it.
Now there are a lot of platforms that do not behave this way. If you ever end up doing embedded work, you are quite likely to end up on a platform where you have to manage all of your own resources (manually free memory, close file handles, etc.)
在具有分离的内核和用户空间以及内存管理器的现代操作系统中，每个用户进程只看到虚拟内存（正如您所说），任何给定的用户进程通常确实不可能损害操作系统（当然不包括这些东西）就像特权用户故意弄乱系统内存一样）。这就是多进程多任务操作系统的全部思想：让操作系统管理许多并发进程，并且不必依赖进程的协作。
（也就是说，如果内存泄漏是由于无效访问错误引起的，那么您仍然容易受到代码注入的影响，而系统其他部分中的特权提升漏洞可能会进一步加剧这种情况，因此进程的隔离只能到此为止。）
In modern operating systems with separated kernel and user space and a memory manager, in which every user process only sees virtual memory (as you said), it is generally indeed not possible for any given user process to hurt the OS (excluding of course things like privileged users deliberately messing with the system memory). That's the entire idea of multi-process multi-tasking operating systems: Having many simultaneous processes managed by the OS, and not having to rely on the processes being cooperative.
(That said, if memory leaks are due to invalid access bugs, you are still susceptible to code injection, which can be further aggravated by privilege elevation vulnerabilities in other parts of your system, so the insulation of a process only goes so far.)
如果您只是获取了超出实际需要的堆，那么当进程退出时，它将被回收。
我不清楚你如何知道在这种情况下你正在泄漏内存，但假设你确实这样做了，那么你仍然应该修复它。这是您代码中的定时炸弹。
原因有两个示例：
您可能遇到可扩展性问题：
对于（一些事情的列表）
做一些泄漏 100 字节的工作
现在迭代 10 次，泄漏 1,000 字节，终止，没什么大不了的。未来你交互 10,000 次，必要的关闭工作会因内存不足而失败......
If you're just grabbing some more heap than you should really need it will be reclaimed when the process exits.
I'm not clear how you know that you're leaking memory in this situation, but assuming that you are indeed doing so then you should still fix it. It's a time-bomb in your code.
Two examples of why:
You may have scalability issues:
for (some list of things )
do some work that leaks 100 bytes
right now you iterate 10 times, leak 1,000 bytes, terminate, no big deal. In the future you interate 10,000 times and essential shut-down work fails due to out-of-memory ...