Setting an Object to Null VS Dispose()

Setting an object to null vs Dispose()

It's important to separate disposal from garbage collection. They are completely separate things, with one point in common which I'll come to in a minute.

Dispose, garbage collection and finalization

When you write a using statement, it's simply syntactic sugar for a try/finally block so that Dispose is called even if the code in the body of the using statement throws an exception. It doesn't mean that the object is garbage collected at the end of the block.

Disposal is about unmanaged resources (non-memory resources). These could be UI handles, network connections, file handles etc. These are limited resources, so you generally want to release them as soon as you can. You should implement IDisposable whenever your type "owns" an unmanaged resource, either directly (usually via an IntPtr) or indirectly (e.g. via a Stream, a SqlConnection etc).

Garbage collection itself is only about memory - with one little twist. The garbage collector is able to find objects which can no longer be referenced, and free them. It doesn't look for garbage all the time though - only when it detects that it needs to (e.g. if one "generation" of the heap runs out of memory).

The twist is finalization. The garbage collector keeps a list of objects which are no longer reachable, but which have a finalizer (written as ~Foo() in C#, somewhat confusingly - they're nothing like C++ destructors). It runs the finalizers on these objects, just in case they need to do extra cleanup before their memory is freed.

Finalizers are almost always used to clean up resources in the case where the user of the type has forgotten to dispose of it in an orderly manner. So if you open a FileStream but forget to call Dispose or Close, the finalizer will eventually release the underlying file handle for you. In a well-written program, finalizers should almost never fire in my opinion.

Setting a variable to null

One small point on setting a variable to null - this is almost never required for the sake of garbage collection. You might sometimes want to do it if it's a member variable, although in my experience it's rare for "part" of an object to no longer be needed. When it's a local variable, the JIT is usually smart enough (in release mode) to know when you're not going to use a reference again. For example:

StringBuilder sb = new StringBuilder();
sb.Append("Foo");
string x = sb.ToString();

// The string and StringBuilder are already eligible
// for garbage collection here!
int y = 10;
DoSomething(y);

// These aren't helping at all!
x = null;
sb = null;

// Assume that x and sb aren't used here

The one time where it may be worth setting a local variable to null is when you're in a loop, and some branches of the loop need to use the variable but you know you've reached a point at which you don't. For example:

SomeObject foo = new SomeObject();

for (int i=0; i < 100000; i++)
{
if (i == 5)
{
foo.DoSomething();
// We're not going to need it again, but the JIT
// wouldn't spot that
foo = null;
}
else
{
// Some other code
}
}

Implementing IDisposable/finalizers

So, should your own types implement finalizers? Almost certainly not. If you only indirectly hold unmanaged resources (e.g. you've got a FileStream as a member variable) then adding your own finalizer won't help: the stream will almost certainly be eligible for garbage collection when your object is, so you can just rely on FileStream having a finalizer (if necessary - it may refer to something else, etc). If you want to hold an unmanaged resource "nearly" directly, SafeHandle is your friend - it takes a bit of time to get going with, but it means you'll almost never need to write a finalizer again. You should usually only need a finalizer if you have a really direct handle on a resource (an IntPtr) and you should look to move to SafeHandle as soon as you can. (There are two links there - read both, ideally.)

Joe Duffy has a very long set of guidelines around finalizers and IDisposable (co-written with lots of smart folk) which are worth reading. It's worth being aware that if you seal your classes, it makes life a lot easier: the pattern of overriding Dispose to call a new virtual Dispose(bool) method etc is only relevant when your class is designed for inheritance.

This has been a bit of a ramble, but please ask for clarification where you'd like some :)

Does setting an object to null dispose the object deterministically?

No, it will not.

do this:

    public void Dispose()
{
// check if object has IDisposble implemented
IDisposable disposePricing = pricingEnvironment as IDisposable;
if (disposePricing!=null)
{
disposePricing.Dispose();
}
}

and have a read on this CLR Inside Out article from 2007

Do you need to dispose of objects and set them to null?

Objects will be cleaned up when they are no longer being used and when the garbage collector sees fit. Sometimes, you may need to set an object to null in order to make it go out of scope (such as a static field whose value you no longer need), but overall there is usually no need to set to null.

Regarding disposing objects, I agree with @Andre. If the object is IDisposable it is a good idea to dispose it when you no longer need it, especially if the object uses unmanaged resources. Not disposing unmanaged resources will lead to memory leaks.

You can use the using statement to automatically dispose an object once your program leaves the scope of the using statement.

using (MyIDisposableObject obj = new MyIDisposableObject())
{
// use the object here
} // the object is disposed here

Which is functionally equivalent to:

MyIDisposableObject obj;
try
{
obj = new MyIDisposableObject();
}
finally
{
if (obj != null)
{
((IDisposable)obj).Dispose();
}
}

Disposing Custom Class : Setting NULL VS .Dispose

It depends, do you have managed resources (File handles, sockets, connections, etc....) that need to be gotten rid of along with your object? If yes then you need a Dispose() if your class contains basic types or just information you do not need to dispose and setting to null will give a hint to the GC to clear that memory.

C# calling IDisposable.Dispose() vs making object null


Now it was suggested to me that check if a "having-a" object is
implementing IDisposable then call the dispose method of it.

IDisposable is a pattern that is used to free unmanaged resources that need to be explicitly released, as the GC isn't aware of them. Usually, a class holding unmanaged resources will also implement a finalizer, and for that fact it is actually pro-longing the lifetime of the object, more than necessary. Dispose in those situations usually invokes a call to GC.SupressFinalize, to remove the said object from the finalization queue.

It is usually a good pattern, if you have an IDisposable object, to implement IDisposable yourself in order to make sure the underlying resource gets disposed.

IMHO, if I make the reference null, then the object on heap would be
marked for Collection by GC.

If the member you want to "null out" isn't a static member, then there is (usually) no reason to do so. The compiler is smart enough to optimize it away, and the GC is smart enough to know that there is no longer a reference to the variable and clean it up.

Edit:

As @ScottChamberlain points out, there are cases when a disposable object is still held a reference to, and hence the GC doesn't count it for GC. When disposing of it and nulling it out as well, you hint the GC that it is "ready for collection".

Do I need to check if the object is null before a dispose() command?

It's generally recommend to wrap anything which implements IDisposable with the using statement

using (var a = new HttpWebResponse(...))
{
}

It's the equivalent of writing

var a = new HttpWebResponse(...);
try
{
// use a
}
finally
{
if (a != null)
a.Dispose();
}

Should I even care if the object is null? Can't I just Dispose of it anyway

Well no, because if you attempt to call Dispose on a null object the application will throw a NullReferenceException. Given your circumstance where you feel the using statement isn't a valid option another neat of way tidying this up is to write an extension method e.g.

public static class Ext
{
public static void SafeDispose(this object obj)
{
if (obj != null)
obj.Dispose();
}
}
...
var a = new ...;
a.SafeDispose();

This then would allow you to call the method on a null object.

What is the difference between Dispose and setting reference to null in C#?

The IDisposable interface defines the Dispose method, as well as the possibility to use the "using" syntax. The dispose method of a class can be implemented to release resources, close database connections and any sort of finalizing and cleanup. Just setting the class instance to null won't execute any of the code defined in the dispose method. As a generic rule, if a class implements IDisposable, dispose should be called when you're finished with the class instance.

Why does this variable need to be set to null after the object is disposed?

It's not directly a PowerShell issue. When a using block terminates, the specified object(s) have their Dispose() methods called. These typically do some cleanup operations, often to avoid leaking memory and so forth. However, Dispose() doesn't delete the object. If a reference to it still exists outside the using block (as in this example), then the object itself is still in scope. It can't be garbage-collected because there's still a reference to it, so it's still taking up memory.

What they're doing in your example is dropping that reference. When powershell is set to null, the PowerShell object it was pointing to is orphaned, since there are no other variables referring to it. Once the garbage collector figures that out, it can free up the memory. This would happen at the end of the method anyway (because powershell would go out of scope), but this way you get the system resources back a little sooner.

(Edit: As Brian Rasmussen points out, the .NET runtime is extremely clever about garbage collection. Once it reaches the last reference to powershell in your code, the runtime should detect that you don't need it anymore and release it for garbage collection. So the powershell = null; line isn't actually doing anything.)

By the way, this pattern looks very strange to me. The usual approach is something like this:

using (PowerShell powershell = PowerShell.Create())
{
//...
}

This way, powershell goes out of scope at the end of the using block, right after it's disposed. It's easier to tell where the variable is relevant, and you save some code because you don't need the powershell = null line anymore. I'd even say this is better coding practice, because powershell never exists in an already-disposed state. If someone modifies your original code and tries to use powershell outside the using block, whatever happens will probably be bad.



Related Topics



Leave a reply



Submit