C#: In what cases should you null out references?

Question

The CLR Profiler can also reveal which methods allocate more storage than you expected, and can uncover cases where you inadvertently keep references to useless object graphs that otherwise could be reclaimed by GC. (A common problem design pattern is a software cache or lookup table of items that are no longer needed or are safe to reconstitute later. It is tragic when a cache keeps object graphs alive past their useful life. Instead, be sure to null out references to objects you no longer need.) -- Writing Faster Managed Code

I don't think I've really ever nulled out a reference before. I assume you don't always need to do this, but I guess there also are times when it is important to remember to do it. But, what cases is that? When should you null out references?

Answer 1

You only need to do it when the variable holding the reference is going to stay "alive" but you don't want the reference itself to prevent garbage collection. In other words, if object A holds a reference to object B, and you don't need B any more but A will stay alive for other reasons. Another common example is static variables, which are "alive" for as long as the AppDomain is.

For local variables it's almost never needed, because the GC can detect the last possible point in code where a variable will be accessed. However, if you use a variable declared outside a loop during the first iteration, but you know you won't need it for subsequent iterations, you could set that to null to help the object to become eligible for GC earlier.

In my experience it's very rare to find myself in this situation. I hardly ever deliberate set variables to null for the sake of the GC. Usually all the member variables within an object are "useful" until the object itself becomes eligible for GC. If you find yourself with member variables which aren't useful for the whole lifetime of the object, you might want to see whether that indicates a problem with the design.

Answer 2

It's important if you have long lived objects (like the cache example in your quote) holding references to short lived objects (like the cache items). Other examples of long lived objects could be singleton objects, the Main Form instance in a Windows Forms application, the Application instance of a ASP.NET application etc.

I would like to add a another common pitfull: short lived objects subscribing to events published by long lived objects. As the event publisher holds a reference to all subscribers, the subscribers (like e. g. ASP.NET page or control instances that are needed only for milliseconds) won't be collected if you do not unsubscribe.