When, How, Where and Why to use Dispose

Dispose, Part 1
What does that pesky Dispose(bool disposing) method do for me?

On a blank form, you’ll see several lines generated:

private System.ComponentModel.Container components = null;
protected override void Dispose( bool disposing ) {
if( disposing ) {
if (components != null) {
components.Dispose();
}
}
base.Dispose( disposing );
}

Essentially this is placeholder code for when you add a component that isn’t a control to the form. When the form disposes, this code is there to dispose it’s associated components. The best example of this is the System.Windows.Forms.Timer and System.Windows.Forms.ToolTip.

If I drop on a timer from the toolbox onto the form and look in InitializeComponent, there are two new lines generated:

this.components = new System.ComponentModel.Container();
this.timer1 = new System.Windows.Forms.Timer(this.components);

Essentially, the constructor of Timer has just added itself to the components collection. When the form is in the process of disposing it will dispose the timer.

 

Dispose - Part 2
What is the purpose of the two dispose methods on Control & Component, etc?

Several pieces of background information:

• Component implements IDisposable
• Control inherits Component, thus inheriting IDisposable.
• IDisposable has one method called Dispose()
• Garbage collection (Finalization) happens on a different thread

Component (base class of Control) has the following pattern:

~Component() {
// I am in the finalizer
Dispose(/*currently disposing=*/false);
}

Dispose() {
// I’ve been told to clean up outside the finalizer
Dispose(/*currently disposing=*/true);

}

protected virtual void Dispose(bool disposing) {
if (disposing) {
// do stuff that can only be done from the main thread.
}
else {
// this is the finalizer thread. Be wary of touching other
// objects as they may have already finalized.
}
// do cleanup actions that can be done either from the finalizer
// thread or the main thread.
}

In other words Dispose(bool disposing) is the unified place for cleanup code. It is called from both the Finalizer and when someone explicitly calls the IDisposable.Dispose method.

If you want to prevent the finalizer from getting called, you can call GC.SupressFinalize from this method if disposing is true.

Here's a more in depth article on how to implement Dispose and Close methods. One little known fact: If you implement Dispose, you should allow it to be called multiple times.

Next time: Can I just let the GC get everything? When do I have to worry about Dispose?

 

Dispose, Part 3
Can I just let the GC get everything? When do I have to worry about Dispose?

If the object implements IDisposable then you should think about how the object is getting cleaned up.Objects that implement IDisposable usually do so because they are holding on to real resources that should be freed deterministically.

Rule of thumb: If the object implements IDisposable then you should think about how the object is getting cleaned up.

When a control is disposed, it disposes all of its children. The only time you get automagic disposal of controls is when you do Application.Run(new Form()). (We like to call this showing the form modelessly). When the form gets WM_CLOSE message, it starts cleaning itself up while it can.

However if you do a Form.ShowDialog(), the form is NOT disposed. (We like to call this showing the form modally). This is because you may want to go in after the form has closed and look at the state of the child controls to determine the next action of your program.

If you add and remove controls from your form dynamically, you should call dispose on them – otherwise you’ll accumulate extra unwanted window handles in your process. Remember you only have to dispose the topmost control – so if you’re swapping in and out a panel – disposing the panel disposes it’s child controls.

Dispose is not just for controls though – Brushes, Pens, and Fonts implement IDisposable as well. These hold onto GDI objects, not window handles. If you leak these objects, it can cause quite a perf problem in your application as System.Drawing may start to GC extra times to get the number of handles back in check. SystemPens and SystemBrushes do not need to be disposed – these are cached objects. SystemFonts do as they are a live fetch from the OS of the current MenuFont etc.

However, if you are creating a new control that holds onto its own IDisposable object (e.g. it’s own tooltip), that control should override Dispose(bool disposing) and add calls to Dispose() for these objects.

If you are concerned about a leak in your code – bring up task manager, switch to processes. View->Select Columns and tick off USER objects and GDI objects. This should show you the live count of how many handles you have out.

In summary

Modeless Form (Application.Run(new Form)) - NO
SystemPens, SystemBrushes - NO

Modal Form (Form.ShowDialog) - YES
Dynamic panel that’s swapped in and out - YES
Pens, Brushes, Fonts, Graphics objects - YES
Regions, other advanced System.Drawing objects - YES
SystemFonts (these are not cached) - YES
Timers, Tooltips, other components - YES

Next time: interesting uses of dispose

 

Dispose - Part 4
Cool things you can do with dispose

Now that we're all convinced that using Dispose is the greatest thing next to sliced bread, lets look at some syntatic sugar in C# that makes life just that much better.

If you are thinking of creating an IDisposable object, then disposing it within the same function, the conscientious thing to do is something like this:

Graphics g = Graphics(this.Handle);
try {
g.DrawRectangle(..);
}finally {
if (g != null) {
g.Dispose();
}
}

It turns out that C# already has a keyword for this - the using statement. The same thing can be expressed as such:

using (Graphics g = Graphics.FromHwnd(this.Handle)) {
g.DrawRectangle(..);
}

It turns out this syntax is also great for defining things like transactions...

using (new MyTransaction()) { ... }

where the MyTransaction class or struct implements IDisposable. If this is the common usage of MyTransaction, consider making it a struct instead of a class so your object will be allocated on the stack, not the heap.

Links:

IDisposable.Dispose remarks section
Performance Considerations for Run-Time Technologies in the .NET Framework
Writing High-Performance Managed Applications : A Primer
Implementing Finalize and Dispose To Clean Up Unmanaged Resources
C# Language Specification: The using statement

Comments

• Anonymous
  August 31, 2005
  Custom PaintingPainting best practices ComboBox OwnerDrawLayoutDock layout/Using the Splitter control...
• Anonymous
  May 02, 2006
  I got a note from Mukund, who is investigating a memory leak problem. 
  
  Hi Jessica, Is it true...
• Anonymous
  September 18, 2006
  Finding leaks
  This article describes the various methods for tracking down GDI and User handle...