Problem
Should you return all of the objects to null (Nothing in VB.NET) when you’re done with them?
Although the object can still be anything after it is discarded (thus the isDisposed attribute in forms), I think it can still live in memory, at least in part.
I’m also aware that when an item is no longer in scope, it is marked for collection, ready for the trash collector’s next pass (although this may take time).
So, with this in mind, will setting it to null speed up the system’s memory release because it won’t have to figure out that it’s no longer in scope, and will there be any negative consequences?
MSDN articles never do this in examples, but I do it since I see no harm in it. However, I’ve come across a wide range of viewpoints, so any feedback is welcome.
Asked by John
Solution #1
There is no need to set objects to null after use, as Karl correctly points out. Just make sure you call IDisposable if an object implements it. When you’re done with an object (wrapped in a try..finally or a using() block), call dispose(). However, even if you forget to call Dispose(), the object’s finaliser function should call Dispose() for you.
This was an excellent treatment, in my opinion:
and this
It’s pointless to try to estimate the GC’s management tactics because the GC is self-tuning and opaque. On Dot Net Rocks, Jeffrey Richter had a great talk on the inner workings: Jeffrey Richter on the Windows Memory Model, and chapter 20 of Richter’s book CLR via C# is excellent:
Answered by Kev
Solution #2
Another reason to avoid setting objects to null after you’re done with them is that it may prolong their life.
e.g.
void foo()
{
var someType = new SomeType();
someType.DoSomething();
// someType is now eligible for garbage collection
// ... rest of method not using 'someType' ...
}
After the call to “DoSomething,” the object addressed by someType will be GC’d, but
void foo()
{
var someType = new SomeType();
someType.DoSomething();
// someType is NOT eligible for garbage collection yet
// because that variable is used at the end of the method
// ... rest of method not using 'someType' ...
someType = null;
}
It’s possible that the object will be kept alive until the method finishes. The assignment to null is normally optimized away by the JIT, thus both pieces of code are identical.
Answered by Wilka
Solution #3
No, you should not use null objects. More detail is available at https://web.archive.org/web/20160325050833/http://codebetter.com/karlseguin/2008/04/28/foundations-of-programming-pt-7-back-to-basics-memory/, however changing things to null will just make your code dirty.
Answered by Karl Seguin
Solution #4
In general, null objects after use aren’t necessary, however in some circumstances, I think it to be a good practice.
I believe it is best to null an object that implements IDisposable and is kept in a field in order to avoid using the discarded object. Bugs of the following kind can be extremely painful:
this.myField.Dispose();
// ... at some later time
this.myField.DoSomething();
After disposing of a field, it’s a good idea to null it and get a NullPtrEx right at the line where the field is utilized again. Otherwise, you might encounter a mysterious bug down the road (depending on exactly what DoSomething does).
Answered by dbkk
Solution #5
If you need to null variables, it’s likely that your code isn’t well-structured enough.
There are several methods for limiting the scope of a variable:
Steve Tranby mentioned it,
using(SomeObject object = new SomeObject())
{
// do stuff with the object
}
// the object will be disposed of
Curly brackets can be used in a similar way:
{
// Declare the variable and use it
SomeObject object = new SomeObject()
}
// The variable is no longer available
I’ve found that using curly brackets without any “header” helps to clean up the code and make it easier to understand.
Answered by mbillard
Post is based on https://stackoverflow.com/questions/2785/setting-objects-to-null-nothing-after-use-in-net