In the article, Coding New Instances of Objects, I wrote about the various ways that New instances of objects can be created. The opposite problem, disposing an object, is something that you won't have to worry about in VB.NET very often. .NET includes a technology called Garbage Collector (GC) that usually takes care of everything behind the scenes silently and efficiently. But occasionally, usually when using file streams, sql objects or graphics (GDI+) objects (that is, unmanaged resources), you may need to take control of disposing objects in your own code.
First, some background.
Just as a constructor (the New keyword) creates a new object, a destructor is a method that is called when an object is destroyed. But there's a catch. The people who created .NET realized that it was a formula for bugs if two different pieces of code could actually destroy an object. So the .NET GC is actually in control and it's usually the only code that can destroy the instance of the object. The GC destroys an object when it decides to and not before. Normally, after an object leaves scope, it is released by the common language runtime (CLR). The GC destroys objects when the CLR needs more free memory. So the bottom line is that you can't predict when GC will actually destroy the object.
(Welllll ... That's true nearly all of the time. You can call GC.Collect and force a garbage collection cycle, but authorities universally say it's a bad idea and totally unnecessary.)
For example, if your code has created a Customer object, it may seem that this code will destroy it again.
Customer = Nothing
But it doesn't. (Setting a an object to Nothing is commonly called, dereferencing the object.) Actually, it just means that the variable isn't associated with an object anymore. At some time later, the GC will notice that the object is available for destruction.
By the way, for managed objects, none of this is really necessary. Although an object like a Button will offer a Dispose method, it's not necessary to use it and few people do. Windows Forms components, for example, are added to a container object named components. When you close a form, its Dispose method is called automatically. Usually, you only have to worry about any of this when using unmanaged objects, and even then just to optomize your program.
The recommended way to release any resources that might be held by an object is to call the Dispose method for the object (if one is available) and then dereference the object.
Customer.Dispose()
Customer = Nothing
Because GC will destroy an orphaned object, whether or not you set the object variable to Nothing, it's not really necessary.
Another recommended way to make sure that objects are destroyed when they're not needed anymore is to put the code that uses an object into a Using block. A Using block guarantees the disposal of one or more such resources when your code is finished with them.
In the GDI+ series, the Using block is put to use quite frequently to manage those pesky graphics objects. For example ...
Using myBrush As LinearGradientBrush _
= New LinearGradientBrush( _
Me.ClientRectangle, _
Color.Blue, Color.Red, _
LinearGradientMode.Horizontal)
<... more code ...>
End Using
myBrush is disposed of automagically when the end of the block is executed.
The GC approach to managing memory is a big change from the way VB6 did it. COM objects (used by VB6) were destroyed when an internal counter of references reached zero. But it was too easy to make a mistake so the internal counter was off. (Because memory was tied up and not available to other objects when this happened, this was called a "memory leak".) Instead, GC actually checks to see whether anything is referencing an object and destroys it when there are no more references. The GC approach has a good history in languages like Java and is one of the big improvements in .NET.
On the next page, we look into the IDisposable interface ... the interface to use when you need to Dispose unmanaged objects in your own code.
