Implementing Finalize and Dispose to Clean Up Unmanaged Resources
Class instances often encapsulate control over resources that are not managed by the runtime, such as window handles (HWND), database connections, and so on. Therefore, you should provide both an explicit and an implicit way to free those resources. Provide implicit control by implementing the protected Finalize Method on an object (destructor syntax in C# and the Managed Extensions for C++). The garbage collector calls this method at some point after there are no longer any valid references to the object.
In some cases, you might want to provide programmers using an object with the ability to explicitly release these external resources before the garbage collector frees the object. If an external resource is scarce or expensive, better performance can be achieved if the programmer explicitly releases resources when they are no longer being used. To provide explicit control, implement the Dispose method provided by the IDisposable Interface. The consumer of the object should call this method when it is done using the object. Dispose can be called even if other references to the object are alive.
Note that even when you provide explicit control by way of Dispose, you should provide implicit cleanup using the Finalize method. Finalize provides a backup to prevent resources from permanently leaking if the programmer fails to call Dispose.
For more information about implementing Finalize and Dispose to clean up unmanaged resources, see Programming for Garbage Collection. The following code example illustrates the basic design pattern for implementing Dispose.
' Design pattern for a base class.
Public Class Base
' Implement IDisposable.
Public Overloads Sub Dispose() Implements IDisposable.Dispose
Protected Overloads Overridable Sub Dispose(disposing As Boolean)
If disposing Then
' Free other state (managed objects).
' Free your own state (unmanaged objects).
' Set large fields to null.
Protected Overrides Sub Finalize()
' Simply call Dispose(False).
' Design pattern for a derived class.
Public Class Derived
Protected Overloads Overrides Sub Dispose(disposing As Boolean)
If disposing Then
' Release managed resources.
' Release unmanaged resources.
' Set large fields to null.
' Call Dispose on your base class.
' The derived class does not have a Finalize method
' or a Dispose method with parameters because it inherits
' them from the base class.
// Design pattern for a base class.
public class Base: IDisposable
public void Dispose()
protected virtual void Dispose(bool disposing)
// Free other state (managed objects).
// Free your own state (unmanaged objects).
// Set large fields to null.
// Use C# destructor syntax for finalization code.
// Simply call Dispose(false).
// Design pattern for a derived class.
public class Derived: Base
protected override void Dispose(bool disposing)
// Release managed resources.
// Release unmanaged resources.
// Set large fields to null.
// Call Dispose on your base class.
// The derived class does not have a Finalize method
// or a Dispose method with parameters because it inherits
// them from the base class.
For a more detailed code example illustrating the design pattern for implementing Finalize and Dispose, see Implementing a Dispose Method.
Customizing a Dispose Method Name
Occasionally a domain-specific name is more appropriate than Dispose. For example, a file encapsulation might want to use the method name Close. In this case, implement Dispose privately and create a public Close method that calls Dispose. The following code example illustrates this pattern. You can replace Close with a method name appropriate to your domain.
' Do not make this method overridable.
' A derived class should not be allowed
' to override this method.
Public Sub Close()
' Call the Dispose method with no parameters.
// Do not make this method virtual.
// A derived class should not be allowed
// to override this method.
public void Close()
// Call the Dispose method with no parameters.
The following rules outline the usage guidelines for the Finalize method:
Only implement Finalize on objects that require finalization. There are performance costs associated with Finalize methods.
If you require a Finalize method, you should consider implementing IDisposable to allow users of your class to avoid the cost of invoking the Finalize method.
Do not make the Finalize method more visible. It should be protected, not public.
An object's Finalize method should free any external resources that the object owns. Moreover, a Finalize method should release only resources that are held onto by the object. The Finalize method should not reference any other objects.
Do not directly call a Finalize method on an object other than the object's base class. This is not a valid operation in the C# programming language.
Call the base.Finalize method from an object's Finalize method.
Note The base class's Finalize method is called automatically with the C# and the Managed Extensions for C++ destructor syntax.
The following rules outline the usage guidelines for the Dispose method:
- Implement the dispose design pattern on a type that encapsulates resources that explicitly need to be freed. Users can free external resources by calling the public Dispose method.
- Implement the dispose design pattern on a base type that commonly has derived types that hold on to resources, even if the base type does not. If the base type has a close method, often this indicates the need to implement Dispose. In such cases, do not implement a Finalize method on the base type. Finalize should be implemented in any derived types that introduce resources that require cleanup.
- Free any disposable resources a type owns in its Dispose method.
- After Dispose has been called on an instance, prevent the Finalize method from running by calling the GC.SuppressFinalize Method. The exception to this rule is the rare situation in which work must be done in Finalize that is not covered by Dispose.
- Call the base class's Dispose method if it implements IDisposable.
- Do not assume that Dispose will be called. Unmanaged resources owned by a type should also be released in a Finalize method in the event that Dispose is not called.
- Throw an ObjectDisposedException from instance methods on this type (other than Dispose) when resources are already disposed. This rule does not apply to the Dispose method because it should be callable multiple times without throwing an exception.
- Propagate the calls to Dispose through the hierarchy of base types. The Dispose method should free all resources held by this object and any object owned by this object. For example, you can create an object like a TextReader that holds onto a Stream and an Encoding, both of which are created by the TextReader without the user's knowledge. Furthermore, both the Stream and the Encoding can acquire external resources. When you call the Dispose method on the TextReader, it should in turn call Dispose on the Stream and the Encoding, causing them to release their external resources.
- You should consider not allowing an object to be usable after its Dispose method has been called. Recreating an object that has already been disposed is a difficult pattern to implement.
- Allow a Dispose method to be called more than once without throwing an exception. The method should do nothing after the first call.