在.NET中，内存管理是自动进行的。内存的再收集属于后台任务，这使开发者们更专注于手边的工作。在这篇文章中，我们来看一看为开发者提供帮助并且控制垃圾收集的接口。
处理设计模式（Dispose design pattern）: IDisposable, Dispose, Finalize
共同语言运行时(CLR)无法清理数据库连接、窗口句柄、文件句柄一类的资源。因此，为开发者提供清理这类难管理的资源的机制是很有必要的。清理工作可以在Finalize方法中实现，Finalize方法在C#语言中被实现为垃圾破坏者。该方法的调用在垃圾收集器的控制下进行。
通常，你会需要一个确定的方法来清理像文件句柄一类难管理的资源。例如，现在你打开了一个文件进行写操作，当你结束将文件内容载入缓冲器后，你可能需要明确的关闭文件句柄。对于这类显式清理，.NET提供了处理设计模式（dispose design pattern） 需要进行显示清理的对象需实现IDisposable接口。IDisposable接口提供了Dispose方法，该方法不像Finalize方法，它不在开发者的控制之下。
既然Dispose方法的调用是显示清理，使用垃圾收集器收集这些对象没有必要。因此Dispose方法应该包含一个对GC.SuppressFinalize()的调用，提示垃圾收集器在这个对象上不需要使用Finalize方法。 推荐在一个需要进行显示清理的对象上同时实现Finalize 和Dispose方法。Finalize方法在Dispose方法没有被调用时提供一个备份的机制。垃圾收集器将执行对象的终结和防止难管理的资源的永久性泄漏。
在 Listing A中的代码片断更清晰的描述了这些概念。
在Listing A中，SampleClass类使用了一个文件句柄，这是一个难管理的资源。因此，应为该对象实现IDisposable接口和提供Finalize方法。
用来清理文件句柄的代码是Dispose方法的一部分。GC.SuppressFinalize()在难管理资源被清除时也将被调用。 该类同时提供了垃圾破坏器（Finalize方法），也包含了用于清理难管理资源（文件句柄）的代码。
.NET框架提供了另一有趣的特色，被用于实现多样的高速缓存。在.NET中弱引用通过System.WeakReference类实现。弱引用为引用的对象提供一项机制，使被引用的对象能够被垃圾收集器作用。ASP.NET高速缓存就使用了弱引用。如果内存使用率太高，高速缓存将被清除。
.NET框架为开发者提供System.GC类来控制垃圾收集器的一些方面。垃圾收集可以通过调用GC.Collect方法强制执行。通常建议不要手动的调用垃圾收集器，而将其设置为自动方式。在某些情况下，开发者会发现强制垃圾收集将推进性能。但是，使用这个方法需要非常小心，因为在垃圾收集器运行时将延缓当前执行的线程。GC.Collect方法不应位于可能被经常调用的地方。这样做将使应用程序的性能降级。
.NET构架包括相同的CLR的两种版本，分别对应于特定的目的。将他们分类为服务器运行时和工作站运行时，并分别在mscorsvr.dll和mscorwks.dll中实现。服务器版的CLR利用多处理技术使垃圾收集可以并行的完成。在单处理器环境使用工作站版本而不能使用服务器版本。
同样，对于垃圾收集器有高级设置项：concurrent garbage collection和nonconcurrent garbage collection。nonconcurrent设置用于服务器环境，这时应用程序无需做出响应。Concurrent设置使用在客户端环境中，这时用户界面被显示且应用程序需做出响应
Microsoft在Visual Studio.NET项目模块上创建了一些缺省设置，ASP.NET应用程序能够利用多处理器与装载CLR的服务器版本。但是，由于Windows客户端通常是胖客户端，它将装载CLR的工作站版本。
可以使用CorBindToRuntimeEx API来覆盖这些设置和控制在多处理器环境中将加载哪种版本的CLR
在两种版本的CLR中配合使用处理设计模型，开发者可以清理难于管理的资源。.NET框架提供面向垃圾收集的构架，将开发者从内存整理工作中解脱出来。这时，开发者只需要管理他使用过某些资源，因此使得工作变得简易同时提高了工作效率。
