C# Frequently Asked Questions

The C# team posts answers to common questions

Should I assign null to my local variables?

Q: Should I assign null to my local variables after I use them?

For example:

string s = ...;
Console.WriteLine(s);
s = null;

A: There is rarely a need to do this for local variables in C#

The lifetime of variables is tracked by the JIT - it analyzes how variables are used in a routine, and it knows exactly when the variable is no longer needed, and after that point, the value is available to be collected.

Interestingly, if you assign it to null, you are actually extending the lifetime of the variable slightly, so it could cause it to be garbage collected later (though realistically, there's unlikely to be any real difference here.

This is true for the vast majority of methods. If you have a method where your code lives for a while - a loop on a separate thread, for example - then it may be worthwhile to see if there are any unnecessary values living in variables while you wait.

 

 

 

 

 

 

 

[Author: Eric Gunnerson]

Published Friday, March 26, 2004 8:15 PM by CSharpFAQ

Comments

 

Paul Wilson said:

.NET Garbage Collection Myth #1:

There is never any reason to setting your objects to null (or nothing in VB) since the GC will do this for you automatically.

Fact:

There are times where setting your objects to null (or nothing in VB) can make huge differences in your memory footprint.

The details and downloadable code to reproduce this is on my blog:

http://weblogs.asp.net/pwilson/archive/2004/02/20/77422.aspx

Yes, this is only an issue in some rather odd cases, and I would agree a better design would not have had the same degree of issues, but the irrefutable point is that sometimes setting objects to null does make a difference, so lets please avoid the overly simplistic answers since some of us really do work in large enterprise systems.
March 27, 2004 4:37 AM
 

Jon Skeet said:

Eric didn't actually make any overly simplistic answers - hence the "rarely" and "vast majority" rather than "never" and "all".

As you say, a better design usually gets round this as a side effect - and I'd always argue that good design is *especially* important in "large enterprise systems". Keeping methods short and sweet has bigger implications than just this issue, but it usually solves this one as well.

Point of terminology: you can never set an *object* to null - you can only set a *variable's value* to null. The terminology of "setting an object to null" can be very confusing to newcomers (as well as being just plain wrong).
March 27, 2004 10:38 AM
 

Paul Wilson said:

By the way Jon, Eric updated his post after my comment -- thus the overly simplistic answer is not what you see now. I don't have a problem with that, as I am glad he updated it a little, but I did just want to point it out.
March 27, 2004 12:30 PM
 

deepblue said:

If GC is becoming a bottleneck, you might want to consider implementing your own Dispose() call. This way, possibly, you could leave everything else to GC other than the code that you think needs to handle memory efficiently right away.

My 2 cents
April 13, 2004 11:01 AM
 

Miguel de Icaza said:

Well, that is implementation specific to .NET's VM and .NET's JIT engine.

In Mono, since we use a different kind
of garbage collector, setting the variable
to null would help the GC.

Miguel.
April 19, 2004 2:07 PM
 

Jon Skeet said:

Urgh - could I suggest changing that then? It's rather nasty if people ought to start telling the compiler when they've finished with a variable when the information is fairly easily available from the compiled IL.
April 20, 2004 2:16 AM
 

JJBlog said:

May 11, 2004 4:33 PM
 

andy said:

May 17, 2004 10:27 PM
 

ok said:

July 18, 2004 12:30 AM
 

Eric Joe said:

Ping Back来自:blog.csdn.net
September 16, 2004 2:02 AM
 

RebelGeekz said:

December 28, 2004 4:54 AM
 

{ public virtual blog; } said:

January 5, 2005 10:36 AM
 

Objektvernichtung und GarbageCollection | hilpers said:

January 20, 2009 9:18 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker