What do you keep on mind to avoid memory leaks when you write thousands lines of .NET code? I'm a big fan of prevention over inspection , there is a famous example regarding this point which is using a "StringBuilder" to combine strings instead of "String1+String2", so what is else out there from your coding experience?
thanks in advance for sharing your thoughts.
Every DataTable.NewRow() must have a matching DaraTable.Rows.Add(...).
Make sure you always dispose IDisposable objects. Furthermore, try to always use "using (...)" blocks to declare disposable objects.
set root references to null after use.
More info here: If we forget to null out rooted references, the GC is prevented from efficiently freeing memory as quickly as possible, resulting in a larger memory footprint for the application. The problem can be subtle, such as a method that creates a large graph of temporary objects before making a remote call like a database query or call to a Web service. If a garbage collection happens during the remote call, the entire graph is marked reachable and is not collected. This becomes even more costly because objects surviving a collection are promoted to the next generation, which can lead to a midlife crisis.
Be aware of the complexity of everything you do, as far as possible, and think about each situation instead of relying on dogma. For instance, also be aware that using a StringBuilder isn't always the right way to join strings :)
Where possible, try to stream data rather than buffering it - you need to be careful here when it comes to LINQ to Objects, understanding which operators buffer and which stream (and which do both with different sequences).
(Neither of these are really memory "leaks" as such - but I'm thinking about places where you can rapidly use more memory than you expect to.)
Events. Always unsubscribe from events, this is single most leak-providing feature of .NET.
Subscribing to event means "notify and hold me while you are alive", not "notify me while I'm alive". Failing to unsubscribe from event usually leads to large clusters of hanging objects, especially in UI.
something.someEvent += new EventHandler(memoryhog.someMethod);
[...]
something.someEvent += new EventHandler(memoryhog.someMethod);
[...]
something.someEvent -= new EventHandler(memoryhog.someMethod);
If you miss unhooking all the event handlers from an object then the object that implements the event handler will stick around in memory for the lifetime of the object with the event.
The Managed DirectX library had a bug like this, which would cause large memory leaks.
Specific to .NET Compact Framework: you have to dispose all graphics related objects (Graphics, Pen, SolidBrush, Bitmap) explicitly or otherwise they will hang around in memory (not great when you're working with low-memory devices).
Not exactly a memory leak, but the one thing that alwas gets me:
Always Close your SQL connections after using them.
If using COM interop, use Marshal.ReleaseComObject after you are done with the COM object to release the Runtime Callable Wrapper (RCW).
Also, if your COM object has a property or method which returns another COM object, take care to always assign it to a variable and release it afterwards.
I.e. this will leak the object received by GetFirstChild:
string name = myBigComObject.GetFirstChild().Name;
Use istead:
ChildComObject firstChild = myBigComObject.GetFirstChild()
string name = firstChild.Name;
Marshal.ReleaseComObject(firstChild);