What are ways to solve Memory Leaks in C#

Question

I\'m learning C#. From what I know, you have to set things up correctly to have the garbage collector actually delete everything as it should be. I\'m looking for wisdom learn

Answer 1

In general, the less you worry about memory allocation in C#, the better off you are. I would leave it to a profiler to tell me when I'm having issues with collection.

You can't create memory leaks in C# in the same way as you do in C++. The garbage collector will always "have your back". What you can do is create objects and hold references to them even though you never use them. That's a code smell to look out for.

Other than that:

• Have some notion of how frequently collection will occur (for performance reasons)
• Don't hold references to objects longer than you need
• Dispose of objects that implement IDisposable as soon as you're done with them (use the using syntax)
• Properly implement the IDisposable interface

Answer 2

Others have already mentioned the importance of IDisposable, and some of the things to watch out for in your code.

I wanted to suggest some additional resources; I found the following invaluable when learning the details of .NET GC and how to trouble-shoot memory issues in .NET applications.

CLR via C# by Jeffrey Richter is an excellent book. Worth the purchase price just for the chapter on GC and memory.

This blog (by a Microsoft "ASP.NET Escalation Engineer") is often my go-to source for tips and tricks for using WinDbg, SOS, and for spotting certain types of memory leaks. Tess even designed .NET debugging demos/labs which will walk you through common memory issues and how to recognize and solve them.

Debugging Tools for Windows (WinDbg, SOS, etc)

Answer 3

The first thing with GC is that it is non-deterministic; if you want a resource cleaned up promptly, implement IDisposable and use using; that doesn't collect the managed memory, but can help a lot with unmanaged resources and onward chains.

In particular, things to watch out for:

• lots of pinning (places a lot of restrictions on what the GC can do)
• lots of finalizers (you don't usually need them; slows down GC)
• static events - easy way to keep a lot of large object graphs alive ;-p
• events on an inexpensive long-life object, that can see an expensive object that should have been cleaned up
• "captured variables" accidentally keeping graphs alive

For investigating memory leaks... "SOS" is one of the easiest routes; you can use SOS to find all instances of a type, and what can see it, etc.

Answer 4

What are the best ways to get things deleted?

NOTE: the following works only for types containing unmanaged resources. It doesn't help with purely managed types.

Probably the best method is to implement and follow the IDisposable pattern; and call the dispose method on all objects implementing it.

The 'using' statement is your best friend. Loosely put, it will call dispose for you on objects implementing IDisposable.

Answer 5

The main sources of memory leaks I can think of are:

• keeping references to objects you don't need any more (usually in some sort of collection) So here you need to remember that all things that you add to a collection that you have reference too will stay in memory.

• Having circular references, e.g. having delegates registered with an event. So even though you explicitly don't reference an object, it can't get garbage collected because one of its methods is registered as a delegate with an event. In these cases you need to remember to remove the delegate before discarding the reference.

• Interoperating with native code and failing to free it. Even if you use managed wrappers that implement finalizers, often the CLR doesn't clean them fast enough, because it doesn't understand the memory footprint. You should use the using(IDisposable ){} pattern

Answer 6

The best way to ensure that objects get deleted, or in .NET lingo, garbage-collected, is to ensure that all root references (references that can be traced through methods and objects to the first method on a thread's call stack) to an object are set to null.

The GC cannot, and will not, collect an object if there are any rooted references to it, no matter whether it implements IDisposable or not.

Circular references impose no penalty or possibility of memory leaks, as the GC marks which objects it has visited in the object graph. In the case of delegates or eventhandlers it may be common to forget to remove the reference in an event to a target method, so that the object that contains the target method can't be collected if the event is rooted.