UML软件工程组织

代码最优化.NET中的内存管理
作者: ZDNet China

在.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中的服务器和工作站版本

.NET构架包括相同的CLR的两种版本,分别对应于特定的目的。将他们分类为服务器运行时和工作站运行时,并分别在mscorsvr.dllmscorwks.dll中实现。服务器版的CLR利用多处理技术使垃圾收集可以并行的完成。在单处理器环境使用工作站版本而不能使用服务器版本。

同样,对于垃圾收集器有高级设置项:concurrent garbage collectionnonconcurrent garbage collectionnonconcurrent设置用于服务器环境,这时应用程序无需做出响应。Concurrent设置使用在客户端环境中,这时用户界面被显示且应用程序需做出响应

 


Microsoft在Visual Studio.NET项目模块上创建了一些缺省设置,ASP.NET应用程序能够利用多处理器与装载CLR的服务器版本。但是,由于Windows客户端通常是胖客户端,它将装载CLR的工作站版本。

可以使用CorBindToRuntimeEx API来覆盖这些设置和控制在多处理器环境中将加载哪种版本的CLR

工作效率

 

在两种版本的CLR中配合使用处理设计模型,开发者可以清理难于管理的资源。.NET框架提供面向垃圾收集的构架,将开发者从内存整理工作中解脱出来。这时,开发者只需要管理他使用过某些资源,因此使得工作变得简易同时提高了工作效率。


版权所有:UML软件工程组织