Foundations of Programming - Karl Seguin

Chapter 7 - Back to Basics: Memory
Managed Memory Leaks
We already saw an example of what a memory leak looks like in C. Basically, if C# didn't have a garbage
collector, the following code would leak:
private void DoSomething()
{
string name = "dune";
}
Our stack value (a pointer) will be popped off, and with it will go the only way we have to reference the
memory created to hold our string. Leaving us with no method of freeing it up. This isn't a problem in
.NET because it does have a garbage collector which tracks unreferenced memory and frees it. However,
a type of memory leak is still possible if you hold on to references indefinitely. This is common in large
applications with deeply nested references. They can be hard to identify because the leak might be very
small and your application might not run for long enough
Ultimately when your program terminates the operating system will reclaim all memory, leaked or
otherwise. However, if you start seeing OutOfMemoryException and aren't dealing with abnormally
large data, there's a good chance you have a memory leak. .NET ships with tools to help you out, but
you'll likely want to take advantage of a commercial memory profiler such as dotTrace or ANTS Profiler.
When hunting for memory leaks you'll be looking for your leaked object (which is pretty easy to find by
taking 2 snapshots of your memory and comparing them), tracing through all the objects which still hold
a reference to it and correcting the issue.
There's one specific situation worth mentioning as a common cause of memory leaks: events. If, in a
class, you register for an event, a reference is created to your class. Unless you de -register from the
event your objects lifecycle will ultimately be determined by the event source. In other words, if ClassA
(the listener) registers for an event in ClassB (the event source) a reference is created from ClassB to
ClassA. Two solutions exists: de-registering from events when you're done (the IDisposable pattern is
the ideal solution), or use the WeakEvent Pattern or a simplified version.
Fragmentation
Another common cause for OutOfMemoryException has to do with memory fragmentation. When
memory is allocated on the heap it's always a continuous block. This means that the available memory
must be scanned for a large enough chunk. As your program runs its course, the heap becomes
increasingly fragmented (like your hard drive) and you might end up with plenty of space, but spread out
in a manner which makes it unusable. Under normal circumstances, the garbage collector will compact
the heap as it's freeing memory. As it compacts memory, addresses of objects change and .NET makes
sure to update all your references accordingly. Sometimes though, .NET can't move an object: namely
when the object is pinned to a specific memory address.
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
61