.NET constructors and memory management question

Question

Coming from more low-level languages like C++, and seeing how transparent .NET memory management is, I've got a concert about a piece a line of code I've written.

In C++, every object necessarily (dictated design practices and peculiarities of memory management) needs to have a constructor and a destructor. In .NET, destructors aren't needed as often, and there are different patterns of when they are required and how to use them. My question is this. If I have the following like of code (in VB.NET, but equally applies to C#)

Dim myObj As New MyClass( <some parameters here> )

followed by the following line later in code

myObj = New MyClass( <some other parameters> )

will the above cause a memory leak? What is the correct way of thinking about such situations?

Answer 1

No, that will not cause a memory leak. The code you wrote is just fine. The thing you have to remember about C# (and the other .NET languages) is that they are garbage collected .

Unlike C++, where you are explicitly responsible for creating and freeing memory yourself, that's not the case in the managed world of .NET. All you have to worry about is creating the object. When there are no longer any remaining references to it, it becomes eligible for garbage collection. Seriously, I know this sounds weird, given your background in other languages, but you really should just let the garbage collector worry about such things. The "correct way of thinking about such situations" is indeed not to think about them at all!

In fact, the only time that you need to write a destructor (and thus worry about memory management) is if your class makes use of unmanaged objects (such as window handles, GDI+ objects, etc.) or other objects that require explicit closing (file handles, database connections, etc.). In the .NET world, you want to write a destructor as rarely as possible, because there's a slight performance penalty in doing so. The specifics lie in the implementation of the garbage collection algorithm, and at what point the object can be collected, but you shouldn't try to learn all that.

The important thing to remember is that if you do need to "clean up" when the object gets destroyed, you should implement the IDisposable interface , like many of the WinForms classes (eg Control ) do that use unmanaged objects internally.

Here are a couple of good resources for learning more about .NET's garbage collection model:

• Garbage Collection on MSDN
• Garbage Collector Basics and Performance Hints by Rico Mariani
• Garbage Collection: Automatic Memory Management in the MS .NET Framework by Jeffrey Richter
• Understanding Garbage Collection in .NET by Andrew Hunter

Answer 2

Objects in .NET are garbage collected. You don't need to delete them.

Some objects that hold unmanaged state (like something allocated from a C function through P/Invoke), such as System.IO.Stream, will implement a finalizer and IDisposable. You can use these in two ways:

Stream s = ...
...
s.Dispose();

Or the safer way:

using(Stream s = ...)
{
    ...
} // Dispose is called automatically

These objects will be garbage collected eventually even if you don't call Dispose, but there is no guarantee when that will happen so it's usually a good idea to do so.

Any of your own classes that have disposable members should also implement IDisposable to clean them up.

Answer 3

No it will not cause memory leak. Garbage collector will reclaim the previous object.

Memory used by all managed resources will be handled by the Garbage Collector.

Answer 4

Negative. The CLR maintains a reference to all instances with a reference counter; every so often the Memory garbage collector will run and find all references where no piece of code is referencing and it will release that memory.

In your situation, it simply means that at some point in the future, since you no longer reference the original instance of MyClass, the garbage collector will release it's memory for you. This is normal operation; so you don't have to worry about it! =D