Why can .NET not have memory leaks?

Question

Ignoring unsafe code, .NET cannot have memory leaks. I've read this endlessly from many experts and I believe it. However, I do not understand why this is so.

It is my understanding that the framework itself is written in C++ and C++ is susceptible to memory leaks.

• Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?
• Is there something within the framework's code that self-manages and even cures its own would-be memory leaks?
• Is the answer something else that I haven't considered?

Answer 1

Well .NET has a garbage collector to clean things up when it sees fit. This is what separates it from other unmanaged languages.

But .NET can have memory leaks. GDI leaks are common among Windows Forms applications, for example. One of the applications I've helped develop experiences this on a regular basis. And when the employees in the office use multiple instances of it all day long it's not uncommon for them to hit the 10,000 GDI object limit inherent to Windows.

Answer 2

There are already some good answers here, but I want to address one additional point. Let's look very carefully again at your specific question:

---

It is my understanding that the framework itself is written in C++ and C++ is susceptible to memory leaks.

• Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?
• Is there something within the framework's code that self-manages and even cures its own would-be memory leaks?
• Is the answer something else that I haven't considered?

---

The key here is to distinguish between your code and their code. The .Net framework (and Java, Go, python, and other garbage-collected languages) promise that if you rely on their code, your code will not leak memory... at least in the traditional sense. You might find yourself in situations where some objects are not freed as you expect, but these cases are subtly different from traditional memory leaks because the objects are still reachable in your program.

You are confused because you correctly understand that this is not the same thing as saying any program you create can't possibly have a traditional memory leak at all. There could still be a bug in their code that leaks memory.

So now you have to ask yourself: would you rather trust your code, or their code? Keep in mind here that their code is not only tested by the original developers (just like yours, right?), it's also battle-hardened from daily use by thousands (perhaps millions) of other programmers like yourself. Any significant memory leak issues would be among the first things identified and corrected. Again, I'm not saying it's not possible. It's just that it's generally a better idea to trust their code than it is your own... at least in this respect.

Therefore the correct answer here is that it's a variant of your first suggestion:

Is the underlying framework so well-written, that it absolutely does not have any possibility of internal memory leaks?

It's not that there's no possibility, but that it's much safer than managing it yourself. I'm certainly not aware of any known leaks in the framework.

Answer 3

This reference shows how leaks can happen in .Net using weak event patterns. http://msdn.microsoft.com/en-us/library/aa970850.aspx

Answer 4

.NET can have memory leaks.

Mostly, people refer to the Garbage Collector, which decides when an object (or whole object cycle) can be gotten rid of. This avoids the classic c and c++ style memory leaks, by which I mean allocating memory and not freeing it later on.

However, many times programmers do not realize that objects still have dangling references and do not get garbage collected, causing a... memory leak.

This is normally the case when events are registered (with +=) but not unregistered later on, but also when accessing unmanaged code (using pInvokes or objects that use underlying system resources, such as the filesystem or database connections) and not disposing properly of the resources.