the SPSite class and SPWeb class objects, are created as managed objects. However, these objects use unmanaged code and memory to perform the majority of their work.
The managed part of the object is small; the unmanaged part of the object is much larger.
Because the smaller managed part of the object does not put memory pressure on the garbage collector, the garbage collector does not release the object from memory in a timely manner.
The object's use of a large amount of unmanaged memory can cause some of the unusual behaviors described earlier.
Calling applications that work with IDisposable objects in Windows SharePoint Services must dispose of the objects when the applications finish using them. You should not rely on the garbage collector to release them from memory automatically
try, catch, and finally blocks
More information can be found at the SharePoint Best Practice Site
Microsoft SharePoint Team announced yesterday that
Microsoft wants to help developers build better quality code that manages available memory better. We are now building a console tool that will help to evaluate customer code against the guidance that is provided. The tool, called SPDisposeCheck, will open your custom compiled assemblies recursively and validate them against the Microsoft published guidance. The output from the tool will contain messages that may indicate the SPSite and SPWeb Dispose() methods guidance are not being followed in the customers source code. While these messages need expert evaluation in order to determine if the software is not performing properly, in some cases just running the tool on your custom code can lead you to simple fixes that improve the quality and performance of custom code on SharePoint.
This tool is planned for release during the coming North American Winter.
More information can be found at the Microsoft SharePoint Team Blog