Theoretical Question : Explicit Object 'Destruction'

  • Thread starter Thread starter jdn
  • Start date Start date
J

jdn

I've read various things about this and am not sure what the 'best
practice' (hate that phrase but there you go) procedure is.

Suppose in a class I have something like:

Object myObject;

where Object is some class I've created.

I do things with myObject. Instantiate it, pass data to and from it,
kick it around, in various methods.

Within those methods, should I do:

myObject = null;

or not? I've read various threads in Google etc. and some say that
since garbage collection is set up a certain way for .NET, you don't
need to do this; others say it is still a good idea.

I haven't been able to find on MSDN a definitive answer (not that it
isn't there, just haven't found it). So what is it?

BTW, myObject is not a SQL connection, etc.

TIA

jdn
 
[Long post, sorry]
I've not seen a best practice from Microsoft, so I'm afraid all you'll
get are more opinions. Mine is to avoid the extra code and typing
since I haven't seen or heard of any advantage to assigning a variable
to null.

I guess I'd be curious when in the methods are you tempted to assign
to null? I can contrive an example when assigning to null could help
out:

If your class instance is going to be around for a long time, and you
are just using myObject for a short time (and it's a big object) then
it might very well make sense to assign to null. For example if you
call setup() and execute() and then it's a long time before another
call to setup() and execute(), assigning to null at the end of an
execute could allow the GC to claim the memory used by myObject.

e.g.

public class AroundForever
{
BigObject myObject;

public void setup()
{
myObject = new BigObject();
// I would guess there would be some custom logic here based
on parameters passed in
}

public void execute()
{
// use myObject
// then eliminate the reference to myObject, so that it can be
GC'ed
// this doesn't mean that it IS GC'ed, just that it could be
if the runtime decides it needs more memory.
myObject = null;
}
}

This seems to me to be a somewhat contrived example, but maybe not.

The only other reason I can think of to assign a variable to null is
when trying to go back to some uninitialized state. That is, if you
later have code that uses that variable and checks for the condition
(myObject == null) .

If every one of your methods assigns myObject = null before returning,
it would probably make more sense to make myObject a local variable to
each function. Then there's no reason to assign to null if the
variable is going out of scope anyway, as in this method:
public void method2()
{
Object myObject;
myObject = new Object();
// use myObject
myObject = null; // does nothing useful
}

I don't know if this sheds any light or not.
 
When you are doing using the object you've created and you want it garbage
collected you should set all references that are reachable from a root
object to a null. This means that if myObject is a field in an object that
is reachable (e.g. an object that is used for the lifetime of the
application), then you should set it to a null. If you are passing myObject
as an argument to other methods, then when those methods go out of scope the
argument is no longer reachable so you do not need to set the argument that
refers to myObject to a null.

Also, setting the value to a null does not destroy the object - by itself it
does not cause finalizers to run or the object to be collected.
 
Dave said:
When you are doing using the object you've created and you want it garbage
collected you should set all references that are reachable from a root
object to a null. This means that if myObject is a field in an object that
is reachable (e.g. an object that is used for the lifetime of the
application), then you should set it to a null. If you are passing myObject
as an argument to other methods, then when those methods go out of scope the
argument is no longer reachable so you do not need to set the argument that
refers to myObject to a null.

Also, setting the value to a null does not destroy the object - by itself it
does not cause finalizers to run or the object to be collected.

Yeah, that makes sense to me.

Thanks.

jdn
 
Back
Top