When would dispose method not get called?

Question

I was reading this article the other day and was wondering why there was a Finalizer along with the Dispose method. I read here on SO as to why you might want to add Dispose to the Finalizer. My curiousity is, when would the Finalizer be called over the Dispose method itself? Is there a code example or is it based on something happening on the system the software is running? If so, what could happen to not have the Dispose method run by the GC.

Columbous

Answer 1

The purpose of the finaliser here is simply a safety precaution against memory leaks (if you happen not to call Dispose explicitly). It also means you don't have to dispose your objects if you want them to release resources when the program shutdowns, since the GC will be forced to finalise and collect all objects anyway.

As a related point, it is important to dispose the object slightly differently when doing so from the finaliser.

~MyClass()
{
    Dispose(false);
}

public void Dispose()
{
    Dispose(true);
    GC.SuppressFinalize(this);
}

protected void Dispose(disposing)
{
    if (!this.disposed)
    {
        if (disposing)
        {
            // Dispose managed resources here.
        }
        // Dispose unmanaged resources here.
    }
    this.disposed = true;
}

The reason you do not want to dispose managed resources in your finaliser is that you would actually be creating strong references to them in doing so, and this could prevent the GC from doing it's job properly and collecting them. Unmanaged resources (e.g. Win32 handles and such) should always be explicitly closed/disposed, of course, since the CLR has no knowledge of them.

Desdamonna

And another reason not to dispose of managed resources in your finaliser... It's possible that they might have already been GC'd by the time your finaliser is executed. Trying to dispose them when they've already been collected would cause a runtime error. – Hansom

@Luke: True, but that can be avoided easily enough by setting all your references to null and then doing a null check before disposing. – Desdamonna

@Desdamonna - Where would unregistering of events fall in your example? I understand techincally they would fall under managed, but what if we had some object tied to this class through an event and we dont unregister it in the unmanaged part (assuming the user doesnt call Dispose directly and its left up to the GC to clean it up). Would it be safe/ok to put event unregistering in the managed section to make sure that happens? The side effect could be someone thinks they are Disposing an object, but really it never gets Disposed because of the event link between this class and the other. – Columbous

@SwDevMan81: I understand the source of your concern, but really events are no different to other resources (they're in fact just wrappers around multicast delegates). Nonetheless, event unregistration belongs in the managed block of the Dispose method. Consider that if it is the finaliser calling the Dispose method, you can guarantee that events will be unregistered immediately by the GC as part of finalisation. – Desdamonna

It's useless for an object to have a finalizer attempt to unsubscribe from events to which it is subscribed. The only way the finalizer will run is if the object holding the subscription becomes eligible for garbage collection, in which case the subscription will be moot. – Pecten

"when the program shutdowns, since the GC will be forced to finalise and collect all objects anyway" -- the GC is not forced to run finalizers at shutdown. It usually will have time to, but it is not guaranteed (and obviously won't happen if the program is terminated abnormally). – Thaine

Answer 2

This is mostly there to protect yourself. You cannot dictate what the end user of your class will do. By providing a finalizer in addition to a Dispose method, the GC will "Dispose" of your object, freeing your resources appropriately, even if the user forgets to call Dispose() or mis-uses your class.

Affiance

It's worth mentioning that the GC is non-deterministic, so there's no guarantee of when, or even if, your finaliser will be called. – Hansom

Yes - If your program runs long enough, your object is most likely to get finalized. Also, if it shuts down cleanly, it'll get finalized. But there are no guarantees with the GC - which is part of why IDisposable exists in the first place. – Affiance

Answer 3

The Finalizer is called when the object is garbage collected. Dispose needs to be explicitly called. In the following code the finalizer will be called but the Dispose method is not.

class Foo : IDisposable
{
  public void Dispose()
  {
    Console.WriteLine("Disposed");
  }

  ~Foo()
  {
    Console.WriteLine("Finalized");
  }
}

...

public void Go()
{
  Foo foo = new Foo();
}

Desist

That is not entirely true. The finalizer is called some time after the object would otherwise be eligible for garbage collection (i.e. the application no longer references the instance). However, as the finalizer must be run for the instance, the CLR actually roots the object and thus it is not garbage collected until the finalizer has run. – Rutan

There's also no guarantee that an object will ever be GC'd or that its finalizer will ever be called. That's why it's doubly important to ensure that you dispose of any IDisposable objects correctly. – Hansom

Answer 4

The dispose method must be explicitly called, either by calling Dispose() or by having the object in a using statement. The GC will always call the finalizer, so if there is something that needs to happen before the objects are disposed of the finalizer should at least check to make sure that everything in the object is cleaned up.

You want to avoid cleaning up objects in the finalizer if at all possible, because it causes extra work compared to disposing them before hand (like calling dispose), but you should always at least check in the finalizer if there are objects lying around that need to be removed.

Torre

Answer 5

An important but subtle note not yet mentioned: a seldom-considered purpose of Dispose is to prevent an object from being cleaned up prematurely. Objects with finalizers must be written carefully, lest a finalizer run earlier than expected. A finalizer can't run before the start of the last method call that will be made on an object(*), but it might sometimes run during the last method call if the object will be abandoned once the method completes. Code which properly Dispose an object can't abandon the object before calling Dispose, so there's no danger of a finalizer wreaking havoc on code which properly uses Dispose. On the other hand, if the last method to use an object makes use of entities which will be cleaned up in the finalizer after its last use of the object reference itself, it's possible for the garbage-collector to call Finalize on the object and clean up entities that are still in use. The remedy is to ensure any call method which uses entities that are going to get cleaned up by a finalizer must be followed at some point by a method call which makes use of "this". GC.KeepAlive(this) is a good method to use for that.

(*) Non-virtual methods which are expanded to in-line code that doesn't do anything with the object may be exempt from this rule, but Dispose usually is, or invokes, a virtual method.

Pecten