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

What about if you are using a managed dll but the dll contians unsafe code? I know this is spliting hairs, but if you dont have the source code, then from yourr point of view, you are only using managed code but you can still leak.

Answer 2

.NET can have memory leaks but it does a lot to help you avoid them. All reference type objects are allocated from a managed heap which tracks what objects are currently being used (value types are usually allocated on the stack). Whenever a new reference type object is created in .NET, it is allocated from this managed heap. The garbage collector is responsible for periodically running and freeing up any object that is no longer used (no longer being referenced by anything else in the application).

Jeffrey Richter's book CLR via C# has a good chapter on how memory is managed in .NET.

Answer 3

Here are other memory leaks that this guy found using ANTS .NET Profiler: http://www.simple-talk.com/dotnet/.net-tools/tracing-memory-leaks-in-.net-applications-with-ants-profiler/

Answer 4

The best example I've found was actually from Java, but the same principle applies to C#.

We were reading in text files that consisted of many long lines (each line was a few MB in heap). From each file, we searched for a few key substrings and kept just the substrings. After processing a few hundred text files, we ran out of memory.

It turned out that string.substring(...) would keep a reference to the original long string... even though we kept only 1000 characters or so, those sub-strings would still use several MB of memory each. In effect, we kept the contents of every file in memory.

This is an example of a dangling reference that resulted in leaked memory. The substring method was trying to reuse objects, but ended up wasting memory.

Edit: Not sure if this specific problem plagues .NET. The idea was to illustrate an actual design/optimization performed in a garbage collected language that was, in most cases, smart and useful, but can result in a unwanted memory usage.

Answer 5

Remember, the difference between a cache and a memory leak is policy. If your cache has a bad policy (or worse, none) for removing objects, it is indistinguishable from a memory leak.

Answer 6

If you aren't referring to applications using .NET, which these answers discuss very well, but are actually referring to the runtime itself, then it technically can have memory leaks, but at this point the implementation of the garbage collector is probably nearly bug-free. I have heard of one case in which a bug was found where something in the runtime, or maybe just in the standard libraries, had a memory leak. But I don't remember what it was (something very obscure), and I don't think I would be able to find it again.