Finalize VS Dispose

Finalize vs Dispose

Others have already covered the difference between Dispose and Finalize (btw the Finalize method is still called a destructor in the language specification), so I'll just add a little about the scenarios where the Finalize method comes in handy.

Some types encapsulate disposable resources in a manner where it is easy to use and dispose of them in a single action. The general usage is often like this: open, read or write, close (Dispose). It fits very well with the using construct.

Others are a bit more difficult. WaitEventHandles for instances are not used like this as they are used to signal from one thread to another. The question then becomes who should call Dispose on these? As a safeguard types like these implement a Finalize method, which makes sure resources are disposed when the instance is no longer referenced by the application.

dispose vs finalize how the object free the memory?

You should prevent users of your application from calling an object's Finalize method directly by limiting its scope to protected. In addition, you are strongly discouraged from calling a Finalize method for a class other than your base class directly from your application's code. To properly dispose of unmanaged resources, it is recommended that you implement a public Dispose or Close method that executes the necessary cleanup code for the object. The IDisposable interface provides the Dispose method for resource classes that implement the interface. Because it is public, users of your application can call the Dispose method directly to free memory used by unmanaged resources. When you properly implement a Dispose method, the Finalize method becomes a safeguard to clean up resources in the event that the Dispose method is not called.

// Design pattern for a base class.
public class Base: IDisposable
{
    private bool disposed = false;

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

    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Free other state (managed objects).
            }
            // Free your own state (unmanaged objects).
            // Set large fields to null.
            disposed = true;
        }
    }

    // Use C# destructor syntax for finalization code.
    ~Base()
    {
        // Simply call Dispose(false).
        Dispose (false);
    }
}

// Design pattern for a derived class.
public class Derived: Base
{
    private bool disposed = false;

    protected override void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Release managed resources.
            }
            // Release unmanaged resources.
            // Set large fields to null.
           // Call Dispose on your base class.
            disposed = true;
        }
        base.Dispose(disposing);
    }
    // The derived class does not have a Finalize method
    // or a Dispose method without parameters because it inherits
    // them from the base class.
}

Source: MSND

Difference between destructor, dispose and finalize method

Destructor implicitly calls the Finalize method, they are technically the same. Dispose is available with objects that implement the IDisposable interface.

You may see : Destructors C# - MSDN

The destructor implicitly calls Finalize on the base class of the
object.

Example from the same link:

class Car
{
    ~Car()  // destructor
    {
        // cleanup statements...
    }
}

The Destructor's code is implicitly translated to the following code:

protected override void Finalize()
{
    try
    {
        // Cleanup statements...
    }
    finally
    {
        base.Finalize();
    }
}

Your understanding for the Destructor is right:

From MSDN

The programmer has no control over when the destructor is called
because this is determined by the garbage collector. The garbage
collector checks for objects that are no longer being used by the
application. If it considers an object eligible for destruction, it
calls the destructor (if any) and reclaims the memory used to store
the object. Destructors are also called when the program exits. It is
possible to force garbage collection by calling Collect, but most of
the time, this should be avoided because it may create performance
issues.

what is relation between GC, Finalize() and Dispose?

GC is garbage collection. It is the automatic memory management, that handles cleanup of objects allocated on the managed heap. The .NET GC employs a mark and sweep algorithm. When a garbage collection occurs it basically considers all object in the part of the heap to be cleaned as recoverable. Then it goes through a marking process where it scans for roots. I.e. it identifies objects that are still in use by the application. Having done that the remaining objects are eligible for cleanup. The heap may be compacted as part of the cleanup.

Dispose and finalizer methods both offer an option for cleaning resources, that are not handled by GC. E.g. this could be native handles and the like. They have nothing to do with reclaiming memory on the managed heap.

Dispose must be called explicitly on a type which implement IDisposable. It can be called either through the Dispose() method itself or via the using construct. The GC will not call Dispose automatically.

A finalizer or destructor (as the language specification calls it) on the other hand will automatically be called sometime after the object was eligible for cleanup. Finalize methods are executed sequentially on a dedicated thread.

Dispose() allows deterministic cleanup of resources while a finalizer can act as a safety net in case the user doesn't call Dispose().

If a type implements a finalizer, cleanup of instances is delayed as the finalizer must be called prior to cleanup. I.e. it will require an additional collect to reclaim the memory for instances of the type. If the type implements IDisposable as well, the Dispose method can be called and then the instance can remove itself from finalization. This will allow the object to be cleaned up as if it didn't have a finalizer.

If you want to dig into this, I recommend CLR via C# by Jeffrey Richter. It is a great book and it covers all the gory details of this (I left out a number of details). The new 3rd edition was just released.

What is the difference between finalize and dispose in .net?

Finalizers are run by the Garbage Collection before an object that is eligible for collection is reclaimed. Dispose() is meant for cleaning up unmanaged resources, like network connections, files, handles to OS stuff, &c. It works best in conjunction with the using block where the compiler makes sure that Dispose() will be called immediately once you are done with an object – and also ensures that you cannot work with the object anymore once it's disposed.

Note that finalizers don't have to run, so relying on that can be dangerous:

What this means for you: Your programs cannot rely on finalizers keeping things tidy. Finalizers are a safety net, not a primary means for resource reclamation. When you are finished with a resource, you need to release it by calling Close or Disconnect or whatever cleanup method is available on the object. (The IDisposable interface codifies this convention.)

Careful also with the precise time when an object becomes eligible for collection. Read the article linked above – it's neither scope (a weird word which has noting to do with the lifetime of an object – it's “the region of program text in which it is legal to refer to [a named entity] by its unqualified name.”) nor is it strictly reference counting as an object can become eligible for collection even before the last reference to it goes away.

Why does the traditional Dispose pattern suppress finalize?

The IDisposable pattern is used so that the object can clean up its resources deterministically, at the point when the Dispose method is called by the client code.

The finaliser is only there as a fallback in case the client code fails to call Dispose for some reason.

If the client code calls Dispose then the clean-up of resources is performed there-and-then and doesn't need to be done again during finalisation. Calling SuppressFinalize in this situation means that the object no longer incurs the extra GC cost of finalisation.

And, if your own class only uses managed resources then a finaliser is completely unnecessary: The GC will take care of any managed resources, let those resources themselves worry about whether they need a fallback finaliser. You should only consider a finaliser in your own class if it directly handles unmanaged resources.

What is the difference between the resources disposed in a finalizer to those released in dispose

The only reason you would use it (and its extremely controversial).

A finalizer allows the clearing an object before it will be deleted by a garbage collector. (That's to say, The GC is responsible for calling it, and clearing the object from memory) If the developer forgot to call Dispose() method of an object, then it will be possible to free the unmanaged resources and thus, avoid the leak.

There are many reasons not to, and many ways to get it wrong. In short there is seldom a reason why you need to do this, or want to do it

Use of Finalize/Dispose method in C#

The recommended IDisposable pattern is here. When programming a class that uses IDisposable, generally you should use two patterns:

When implementing a sealed class that doesn't use unmanaged resources, you simply implement a Dispose method as with normal interface implementations:

public sealed class A : IDisposable
{
    public void Dispose()
    {
        // get rid of managed resources, call Dispose on member variables...
    }
}

When implementing an unsealed class, do it like this:

public class B : IDisposable
{    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }   
        // get rid of unmanaged resources
    }

    // only if you use unmanaged resources directly in B
    //~B()
    //{
    //    Dispose(false);
    //}
}

Notice that I haven't declared a finalizer in B; you should only implement a finalizer if you have actual unmanaged resources to dispose. The CLR deals with finalizable objects differently to non-finalizable objects, even if SuppressFinalize is called.

So, you shouldn't declare a finalizer unless you have to, but you give inheritors of your class a hook to call your Dispose and implement a finalizer themselves if they use unmanaged resources directly:

public class C : B
{
    private IntPtr m_Handle;

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            // get rid of managed resources
        }
        ReleaseHandle(m_Handle);

        base.Dispose(disposing);
    }

    ~C() {
        Dispose(false);
    }
}

If you're not using unmanaged resources directly (SafeHandle and friends doesn't count, as they declare their own finalizers), then don't implement a finalizer, as the GC deals with finalizable classes differently, even if you later suppress the finalizer. Also note that, even though B doesn't have a finalizer, it still calls SuppressFinalize to correctly deal with any subclasses that do implement a finalizer.

When a class implements the IDisposable interface, it means that somewhere there are some unmanaged resources that should be got rid of when you've finished using the class. The actual resources are encapsulated within the classes; you don't need to explicitly delete them. Simply calling Dispose() or wrapping the class in a using(...) {} will make sure any unmanaged resources are got rid of as necessary.

Why should Dispose() dispose managed resources and finalizer not?

When an object's finalizer runs, one of the following will be true of almost any IDisposable object it might hold:

It held the only reference to that other object, and that other object's finalizer has already run, so there's no need to do anything with it.
It held the only reference to that other object, and that other object's finalizer is scheduled to run, even though it hasn't yet, and there's no need to do anything with it.
Other objects are still using the IDisposable object, in which case the finalizer must not call Dispose.
The other object's Dispose method cannot be safely run from a finalizer threading context (or, more generally, any threading context other than the one where the object was created), in which case the finalizer must not call Dispose.

Even in the cases where none of the above would apply, code which knows that will probably know a lot about its cleanup requirements beyond the fact that it implements IDisposable, and should often use a more detailed cleanup protocol.

Finalize VS Dispose