What Operating Systems Will Free The Memory Leaks?

2019-05-07 18:21发布

问题:

I've got a desktop program. Most Operating Systems run the program in its own address space.

When the program exits, I believe most operating systems free the memory allocated by the program and return it to the memory stack for reuse.

What I am not sure of, is if the program has a memory leak, will the memory "leaked" also be returned for reuse, or is it lost until the machine is rebooted?

This is a followup to the question I asked earlier today: Do Small Memory Leaks Matter Anymore?, and a couple of comments there mentioned that program memory is freed when a program finishes. If leaks are freed when a program is done, then it definitely puts less pressure on me to rigorously rid my program of the tiniest leaks.

Specifically, I'm a Windows programmer and I need to know what happens (memory lost or memory freed) for Windows 98, 2000, XP, Vista and 7. But I'd also like to hear what happens on Mac and Unix machines.


Clarification: I am talking about non-growing leaks. These are leaks of a constant size that happen once when a program is run.

I do realize that leaks that are continually growing in a program are severe and must be fixed.

Either way, the question isn't about whether or not leaks must be fixed. It is whether or not the Operating Systems give you back the leaked memory when the program ends.

回答1:

A memory leak simply refers to when your program is allocating memory that it then loses track of. The operating system still considers this memory to be in the address space of the program, and thus it will be reused when the program finishes.

All modern operating systems use a mechanism called virtual memory to keep track of a programs memory.

This is where I learned about virtual memory in quite good detail CS3231.

Basically it is where the operating system can put chunks of an applications memory anywhere in physical memory, while maintaining a mapping to where these chunks should point to.

From the applications point of view, it gets full access to memory (4gig on 32-bit OS, something massive on 64-bit), and can keep allocating until it hits the hardware limit, even if physical memory is less than this limit (this requires the OS to store some of the contents of memory on disk, usually in a swap file)

This is facilitated by the hardware on the CPU, a module usually called the MMU (Memory Management Unit), and sometimes there is also a TLB (Translation Lookaside Buffer) to speed up virtual memory operations.

Another page that explains a bit more about Memory Protection which details some more of the inner workings of Virtual Memory.



回答2:

Windows will free your process memory after it terminates but the leak has some impact on your application performance and reliability (depending on its size)

In some ways small leaks are worse than big ones, since they will cause crawling degradation in your software until the inevitable death, possibly taking hours of your users' work with them.

If you do know of memory leaks I suggest you hunt them down and get rid of them, no part of the OS or your programming language will effectively do that for you. There are some very good tools to pinpoint leaks.



回答3:

I, as a professional in my field find the idea of someone not caring if they are doing their job well to be abhorrent. You should strive to do your job well, and that will translate into you writing better programs. Allowing or ignoring memory leaks as "unimportant" means you are more likely to do the same with other things you consider "unimportant", like documentation, or performance, or user friendliness.

A laissez faire attitude breeds problems. So I consider memory leakes to be a sign of how poor you are at your job.

However, having said all that, there are very real reasons not to ignore memory leaks. For instance, you don't know how long your user will run your program. It could be 5 minutes or 5 weeks. Memory leaks build up, and use more and more resources until other things start to fail.

Another issue to keep in mind is that users are not only running your program. They are running other apps as well, and the more resources your app uses, the fewer that are available for their other programs. Ignoring memory leaks is basically being selfish and not caring if your users are having problems.