I内存优化之道：托管代码的失传内存优化技术的再发现.docVIP

内存优化之道：托管代码的失传内存优化技术的再发现原著：Erik Brown翻译：小刀人 原文出处：MSDN Magazine January 2005 原代码下载：MemoryOptimization.exe (136KB)本文讨论以下内容：·对象类型如何对内存使用的影响·对象池机制如何影响垃圾收集·访问大规模数据时的数据流 ·内存使用率分析 本文使用到以下技术：.NET Framework, C#内存是一个所有程序都需要的资源，但是合理的内存使用正在成为一种失传的技术。因为用Microsoft?.NET Framework所写的托管应用程序依靠垃圾收集来分配和清扫内存。对许多应用程序来说，用百分之三到五的CPU时间进行垃圾收集(GC)之于不用操心内存管理是一个相当公平的交易。但对于应用程序来说CPU时间和内存都是宝贵的资源，最小化垃圾收集消耗时间可能较大提升应用程序的性能和健壮性。如果一个应用程序可以更加有效的使用可用内存，这时它表示垃圾收集器运行频次将更少并将花费更少的时间。因此与其考虑垃圾收集器在你的应用程序里这样做或那样做，倒不如直接看看内存使用。大多成品机器都有一个容量巨大的RAM，并且在大多数情况下,比如使用短整数代替常用的优化可能被视为是微不足道的。在本文中我将让你改变这个看法。我将着眼于类型大小，各种设计技巧，以及如何分析一个程序的内存使用。我的例子将集中于C#，但是这个讨论同样适用于Visual Basic?.NET，managed C++，和任何你能想到的.NET目标语言（.NET-targeted languages）我假定你理解垃圾收集工作的基本原理，包括相关概念如：代（generations），释放模式（the disposal pattern），和弱引用（weak references）。如果你不熟悉这些概念，Jeffrey Richter有一篇很好的关于垃圾收集的文章在Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework。 类型大小内存使用最终依赖于你的程序中程序集的已定义和使用的类型，因此让我们先从探究系统中各种类型的大小开始。图 1展示了在System命名空间中定义的核心. NET值类型的字节大小，以及他们对应的C#类型。我使用了非安全代码和C# sizeof操作符来查验这些值类型在托管内存中的大小。对这些类型中的一部分来说，用Marshal.SizeOf方法代替sizeof操作符将导致不同的值，包括bool和char，既然Marshal.SizeOf计算了一个已封送类型的非托管大小，并且这些类型是non-blittable（意思是在托管和非托管代码之间传递时他们可能需要转换）。更多内容很快就要谈到。结构（一种值类型）的大小是其各字段的大小的和，加上所有用来对齐字段的自然边界的附加系统开销。引用类型的大小是其字段上舍入到下一个4字节边界，加上8字节系统开销。（为了解到底你的引用类型用了多少空间，你可以在分配他们时测算一下堆大小的变化，或者你可以使用后面讨论的CLR Profiler工具。）这意味着所有引用类型占用至少12个字节，因此在C#中任何小于16个字节长的对象可能用一个结构会更加有效率些。当然，如果你需要储存一个引用到这个类型时用结构是会有问题的，因为频繁装箱可以耗尽内存和CPU周期。此时，小心使用结构是很重要的。既然字段对齐可以影响一个类型的大小，一个类型内部的字段组织在它最终的大小方面扮演了重要角色。一个类型设计和用那个设计的字段组织受到应用到类型上StructLayoutAttribute的影响。一般情况下，C#，Visual Basic .NET，和C++编译器都应用一个StructLayoutAttribute到结构，指定一个Sequential（顺序的）布局。这意味着这个字段依照它们在源文件中的顺序来布局。然而，在.NET Framework 1.x中，一个Sequential设计请求是不能受到即时编译器(JIT)响应的，尽管它是由封送拆分器提出的。在.NET Framework 2.0中，JIT为值类型的托管布局增强了Sequential 布局（如果指定），虽然只有当它们都是非引用类型字段成员时。因此，类型的大小在下一个版本Framework中可能会更加重要。在所有的版本中，对于一个显式布局（你作为一个开发者指定每个字段偏移量和每个字段的地方）的请求都被JIT 和封送拆分器共同响应。我做此区别是因为一个类型的已封送布局是和该类型的栈或GC堆布局明显地不同。一个已封送类型的布局必须和它的非托管副本一致。