CLR 垃圾回收器 (GC) 将对象分为大型、小型两类。如果是大型对象，与其相关的一些属性将比对象较小时显得更为重要。例如，压缩大型对象（将内存复制到堆上的其他位置）的费用相当高。我将讨论符合什么条件的对象才能称之为大型对象，如何回收这些大型对象，以及大型对象具备哪些性能意义。

大型对象堆

.NET Framework 1.1 和 2.0 中，如果对象大于或等于 85,000 字节，将被视为大型对象。注意：此数字根据性能优化的结果确定。当对象分配请求传入后，如果符合该大小，便会将此对象分配给大型对象堆。为什么会这样呢？我们先看看NET 垃圾回收器的基础知识。

我们知道，.NET 垃圾回收器是分代回收器。它包含三代：第0代、第1代和第2代。之所以分代，是因为在良好调优的应用程序中，您可以在第0代清除大部分对象。每当触发一次垃圾回收，NET就首先扫描第0代，仍存在的对象将被放到第1代，当第1代放满后，会对第1代进行垃圾回收，仍存在的对象将被放到第2代，以此进行下去。但是，最后一代回收未处理的对象仍会被视为最后一代中的对象。从本质上讲，第1代是新对象区域与生存期较长的对象区域之间的缓冲区。回收任何一代，都会回收他以前的所有代。例如，执行第1代垃圾回收时，将同时回收第1代和第0代。执行第2代垃圾回收时，将回收整个堆。

加载 CLR 时，将分配两个初始堆栈段（一个用于小型对象，另一个用于大型对象），我将它们分别称为小型对象堆 (SOH) 和大型对象堆 (LOH)。然后，通过将托管对象置于任一托管堆栈段上来满足分配请求。如果对象小于 85,000 字节，则将其放在 SOH 段上；否则将其放在 LOH 段上。随着分配到各段上的对象越来越多，会以较小块的形式提交这些段。用户代码只能在第 0 代（小型对象）或 LOH（大型对象）中分配。只有垃圾回收器可以在第1代（通过提升第0代回收未处理的对象）和第2代（通过提升第1代和第2代回收未处理的对象）中“分配”对象。触发垃圾回收后，垃圾回收器将寻找存在的对象并将它们压缩。如果没有足够的可用空间来容纳大型对象分配请求，我会先尝试从操作系统获取更多段。如果失败，我将触发第 2 代垃圾回收以便释放一些空间。

如果大家还有所怀疑，可以看看下面windbg+sos来看看一个用户态运行的程序的GC Heap里面都是些什么：

Number of GC Heaps: 1
generation 0 starts at 0x013d1018
generation 1 starts at 0x013d100c
generation 2 starts at 0x013d1000
ephemeral segment allocation context: none
 segment    begin allocated     size
001b09f8 7a733370  7a754b98 0x00021828(137256)
001b3fc0 7b463c40  7b47a744 0x00016b04(92932)
0014df68 790d8620  790f7d8c 0x0001f76c(128876)
013d0000 013d1000  01425ff4 0x00054ff4(348148)
Large object heap starts at 0x023d1000
 segment    begin allocated     size
023d0000 023d1000  023d8e00 0x00007e00(32256)
Total Size   0xb488c(739468)
------------------------------
GC Heap Size   0xb488c(739468)
我们一个GC Heap里面有四个Heap Segment，紧接着Heap Segment的，是LOH。这些Generation是保存在一个一个的Heap Segment里面的。一个Heap Segment可以包含两个Generation或者三个，或者更多。而一个Generation可以跨越多个Heap Segment。紧接着GC Heap的内存区域，就是LOH。在默认情况下，超过85000byte的对象就被保存到这里。

You write:

public enum Compression {

   Zip, SuperZip, None

 }

The C# compiler generates:

public struct Compression : Enum {

   public int value__;

   public const Compression Zip = 0;

   public const Compression SuperZip = 1;

   public const Compression None = 2;

}
What can we learn:
1）Enums 是struct ，内部成员即是struct 也是Enum 。
2）Enum 继承System.Enum 的，structs可以继承ValueType,也可以是Enum 。
3）Enum 内部成员默认是Int的。
4）变量含有”__“的不能使用。
5）所有的值都是const 的，因此在没有重新编译的时候是不能改变的，而且也是类型安全的。
 

You write:

public class Resource

{

   ~Resource() {

      ...

   }

}

The C# compiler generates:

public class Resource

{

   protected override void Finalize() {

      try {

         ...

      }

      finally {

         base.Finalize();

      }

   }

}

What can we learn:
1）解析函数是重写基类的finalize 的。且是不确定的。
2）method (represented by the “…”)是放在Try里，无论有没有异常都会调用基类的finalize 。

The C# compiler generates:
ArrayList list1;
int num1;
IEnumerator enumerator1;
IDisposable disposable1;
list1 = new ArrayList();
enumerator1 = list1.GetEnumerator();
try { 
        while (enumerator1.MoveNext()) { 
            num1 = ((int) enumerator1.Current);
         } 
        return;
 }
finally { 
            disposable1 = (enumerator1 as IDisposable); 
            if (disposable1 != null) { 
                    disposable1.Dispose(); 
                }
}

知道大家都已经熟悉了,代码不多讲,后面附有下载,欢迎大家提出批评.谢谢!

实现方法还有App_LocalResources,但是每个页面都要一个配置文件,麻烦啊.方法类似.

个人感觉用数据库存资源文件的内容似比较好的方式.
大家还有别的实现方法吗(编码方式,不用第三方组件)?

代码下载:/Files/gjcn/WebSite3.rar

1. Bin文件夹

Bin文件夹包含应用程序所需的，用于控件、组件或者需要引用的任何其他代码的可部署程序集。该目录中存在的任何.dll文 件将自动地链接到应用程序。如果在该文件夹中留有不用的或过期的文件，则可能出现“二义性引用(ambiguous reference)”异常的风险。换句话说，如果两个不同的程序集定义相同的类(相同的命名空间和名称)，则ASP.NET运行库不能决定应该使用哪一 个程序集，从而抛出一个异常。在开发时，当我们重新命名一个项目或一个程序集的名称时，这是常见的错误。为了避免这种错误，一定不要在该文件夹中保留任何 不必要的程序集，或者至少要从配置文件的<assemblies>节中删除如下代码行：

<add assembly="*" />

在表1.10所列的所有文件夹中，只有Bin可以被ASP.NET 1.x应用程序识别。该文件夹是强制性的。

2. App_Browser文件夹

该可选的文件夹包含.browser文件。.browser文件描述浏览器(不管是移动设备浏览器，还是台式机浏览器)的特 征和功能。ASP.NET在安装路径下的Config\Browser文件夹中安装了大量.browser文件，这些文件供所有应用程序共享。我们只是把 当前应用程序特有的浏览器文件放在App_Browser文件夹下。.browser文件的内容即时动态地进行编译，以便向ASP.NET运行库提供最新 的浏览器信息。

让我们简单谈谈拥有一个自定义的.browser文件可能有帮助的场景。设想应用程序使用了一个在某个浏览器下不能有效呈现的控件。在指定的浏览器中显示宿主页面时，可以编写一个.browser文件，迫使ASP.NET使用一个不同的适配器来生成该控件。

<browsers>

<browser id="browserID">

<controlAdapters>

<adapter controlType="Samples.CustomControl"

adapterType="Samples.Adapters.CustomControlAdapter" />

</controlAdapters>

</browser>

</browsers>

假设browserID与ASP.NET识别的标准浏览器之一相匹配，则上文所示的.browser文件指示在指定的浏览器下使用CustomControlAdapter呈现CustomControl。

3. App_Code文件夹

App_Code文件夹正好在Web应用程序根目录下，其存储所有应当作为应用程序的一部分动态编译的类文件。这些类文件自 动链接到应用程序，而不需要在页面中添加任何显式指令或声明来创建依赖性。App_Code文件夹中放置的类文件可以包含任何可识别的ASP.NET组件 ——自定义控件、辅助类、build提供程序、业务类、自定义提供程序、HTTP处理程序等。

   注意     在开发时，对App_Code文件夹的更改会导致整个应用程序重新编译。对于大型项目，这可能不受欢迎，而且很耗时。为此，鼓励大家将代码进行模块化处理 到不同的类库中，按逻辑上相关的类集合进行组织。应用程序专用的辅助类大多应当放置在App_Code文件夹中。

App_Code文件夹中存放的所有类文件应当使用相同的语言。如果类文件使用两种或多种语言编写，则必须创建特定语言的子目录，以包含用每种语言编写的类。一旦根据语言组织这些类文件，就要在web.config文件中为每个子目录添加一个设置：

<compilation>

<codeSubDirectories>

<add directoryName="VBFolder" />

</codeSubDirectories>

</compilation>

重要的是，特定语言的子目录应在web.config文件中注册，否则，不管它们属于哪个文件夹，App_Code文件夹下 的所有文件将被编译成一个单独的程序集。上述配置脚本描述了这么一种情况，即所有的C#文件都放在App_Code文件夹的根目录下，而把几个 Visual Basic .NET类文件移入VBFolder目录中。如果<codeSubDirectories>节中提到的目录不存在，则会收到一个编译错误提 示。

App_Code根文件夹中的文件被编译成App_Code_xxx.dll程序集，其中xxx是随机生成的字符序列。一个 给定子目录中的文件将被编译成一个名为App_SubCode_xxx_yyy.dll的动态创建的程序集，其中xxx指示子目录的名称，而yyy是一个 随机字符序列。只有在应用程序根目录中的web.config文件中进行了设置，<codeSubDirectories>节才有效。

在App_Code目录或任何其他子目录中放置一个assemblyinfo.cs文件，可以创建一个强命名的程序集。显然，如果该文件夹包含Visual Basic .NET文件，那么将使用assemblyinfo.vb文件。程序集配置文件可以引用一个.snk文件来保存强名称的密钥。

注意     给一个程序集设置一个强名称，首先必须获得一个公开/私有密钥对。通过使用强名称(Strong Name)工具(sn.exe)，可以获得这样一个密钥对。强名称工具是我们可以在.NET Framework的安装路径中发现的SDK binary之一。密钥对文件通常有一个.snk扩展名。可以将该文件保存到一个应用程序文件夹中，并在assemblyinfo.cs文件中引用它，如下所示：

       [assembly: AssemblyKeyFileAttribute(@"yourKeyPair.snk")]

注意，Visual Basic .NET是在包含Visual Studio Solution的目录中寻找密钥文件，而C#编译器则在包含该binary的目录中寻找密钥文件。据此可知，用此属性调整我们使用的路径，或者把密钥文件放在合适的文件夹中。

在随后发生的任何重新生成中，程序集的名称将发生变化。同时，老的AppDomain请求一结束，就删除老的程序集。

App_Code文件夹并非只能包含类文件。特别是，它可以包含并能自动地处理代表数据架构的XSD文件。把一个XSD文件 添加到该文件夹中时，编译器将把它解析成一个有类型的DataSet类，并将它添加到应用程序作用域中。在ASP.NET 1.x中，这一工作由Visual Studio .NET向导，使用一个命令行实用程序(xsd.exe)完成的。

   注意     使用web.config文件注册一个组件(例如，一个自定义的服务器控件或一个自定义的HTTP处理程序)时，通常要求指定包含该代码的程序集名称。如 果该组件定义在App_Code文件夹中，则应该用什么名称来指示程序集？在这种情况下，只是忽略程序集信息，并规定完整的类名即可。如果没有规定任何程 序集，则ASP.NET运行库将试图从任何已装载的程序集中装入该类，包括为App_Code文件夹动态创建的程序集。

4. App_Data文件夹

App_Data文件夹应该包含应用程序的本地数据存储。它通常以文件(诸如Microsoft Access或Microsoft SQL Server Express数据库、XML文件、文本文件以及应用程序支持的任何其他文件)形式包含数据存储。该文件夹内容不由ASP.NET处理。该文件夹是ASP.NET提供程序存储自身数据的默认位置。

注意     默认ASP.NET帐户被授予对文件夹的完全访问权限。如果碰巧要改变ASP.NET帐户，一定要确保新帐户被授予对该文件夹的读/写访问权。

5. App_GlobalResources文件夹

正如其他应用程序一样，ASP.NET应用程序也可以使用资源，而且通常应该使用资源。资源是隔离应用程序用户界面的可局部 化部分的一种有效方法。一般而言，资源是与程序相关的不可执行的文本。典型的资源有图像、图标、文本和附属文件，但是任何可序列化的对象也可以被看作资 源。应用程序资源存储在应用程序的外部，这样就能在不影响和重新编译应用程序本身的情况下重新编译和替换它们。

ASP.NET应用程序需要有一个主要程序集来保存应用程序默认的或中性的资源。此外，还要部署许多附属程序集，它们中各自 包含我们需要支持的某种文化的本地化资源。在ASP.NET 1.x中，编译一个程序集内的资源有点麻烦。需要手动地将基于XML的资源文件(那些带.res扩展名的资源)编译成.resources二进制文件。这 些文件既可以嵌入到一个.NET可执行文件中，也可以编译成附属程序集。使用资源文件生成器实用程序resgen.exe，将文本和基于XML的资源文件 转变为.resource文件。资源文件名称遵循baseName.cultureName.resource命名约定，其中baseName通常是应用 程序的名称：

resgen.exe ProAspNet20.resx ProAspNet20.it.resources

创建.resource文件以后，应当把它嵌入到一个程序集中，甚至可以作为一个资源容器来使用。要把一个资源文件嵌入到一个附属程序集中，可以使用程序集连接器工具(al.exe)。在命令行上，指出程序集所使用的文化(如下面示例中的it，它代表意大利)和名称。

al /out:ProAspNet20.resources.dll /c:it /embed:ProAspNet20.it.resources

在编译附属程序集之后，它们将有相同的名称。将它们部署到不同的子目录中，分别按文化命名。

幸运的是，对于ASP.NET 2.0，附属程序集的时代已经一去不复返了。更准确地说，附属程序集仍然存在，但是由于App_GlobalResources保留文件夹，对开发人员来说它们已经成为过去的事情。

该文件夹中的任何定位的.resx文件自动地被编译成附属程序 集。.resx文件的名称包含文化信息，以帮助ASP.NET运行库环境的程序集生成。如下文件，resources.resx, resources.it.resx, resources.fr.resx，生成中性程序集以及适合于意大利(Italian)和法国(French)文化的附属程序集。如果没有要求特定文 化，则中性程序集是默认的文化资源。

App_GlobalResources文件夹中的资源文件是应用程序的全局资源，因而可以从任何页面中引用它。和ASP.NET 1.x相比资源读取结果也极大地简化了：

<asp:Label Runat="server" Text="<%$ Resources:ResxFile, MyResName %>" />

可以使用最新的称为Resources的$-表达式以声明的方式绑定全局资源(第5章将详细介绍$-表达式)。该表达式包括两个参数：.resx资源文件的名称(没有扩展名)，以及要检索的资源的名称。以编程的方式访问资源，请使用如下代码：

HttpContext.GetGlobalResourceObject(resxFile, MyResName)

这两个参数都是字符串，并且与$-表达式中的参数具有相同的作用。此外，$-表达式Resources的实现在内部使用GetGlobalResourceObject。

6. App_LocalResources文件夹

App_LocalResources文件夹位于包含一些ASP.NET页面的文件夹下的一个子目录。该文件夹可以使用位于 目录结构中高一级目录中的页面命名的.resx文件进行填充。假定父文件夹包含test.aspx，则可以在App_LocalResources文件夹 中找到一些可用的资源文件如下：test.aspx.resx、test.aspx.it.resx和test.aspx.fr.resx。显然，上述文 件中存储的资源仅对test.aspx页面有影响，因而只能在链接的页面中看见它们(可以使用它们)。

如何访问一个页面特有的资源呢？对于编程访问，可使用如下代码：

HttpContext.GetLocalResourceObject("/ProAspNet20/ResPage.aspx",

"PageResource1.Title")

第1个参数指出页面虚拟路径；第2个参数是资源名称。对于声明式访问，使用meta:ResourceKey属性。例如，

<asp:Button Runat="server" meta:resourcekey="ButtonResource1" />

该声明将一个惟一的资源键与特定按钮实例关联。局部文件.resx包含prefix.name形式的条目，其中prefix 是资源键，而name是绑定控件上的属性名。为了赋予按钮一个本地化标题(Text属性)，只要在资源文件中创建一个 ButtonResource1.Text条目即可。

局部和全局资源文件夹中存在的资源文件都被编译，以创建附属程序集的类。最后的结果是开发人员创建.resx文件，并测试该页面。而ASP.NET编译机制会完成其余工作。

7. App_Themes文件夹

App_Themes文件夹为ASP.NET控件定义主题。主题包含在App_Themes文件夹下的一个文件夹。根据定义，一个主题是一组带有样式信息的文件。主题文件夹中的文件内容被编译，以生成一个类，而该类被页面调用以编程的方式设置主题化控件的样式。

App_Themes文件夹列出应用程序的本地主题。 应用程序还可以继承如下文件夹中定义的全局主题：

%WINDOWS%\Microsoft.NET\Framework\[version]\ASP.NETClientFiles\Themes

从编译的角度看，全局主题和局部主题没有区别。如果一个给定名称的主题，既存在应用程序的本地主题，又存在服务器机器的全局主题，则本地主题优先适用。

8. App_WebReferences文件夹

在Visual Studio .NET 2003中，一个需要访问Web服务的ASP.NET应用程序，将通过“添加Web引用”对话框获得相应的.wsdl文件。Web服务的WSDL(Web Service Description Language)文档，对于从页面使用Web服务是不够的。ASP.NET页面最终是一个托管类，并且需要与另一个托管类通信。因此，Web服务被一个 代理类所包装。该代理类是由Visual Studio使用命令行工具wsdl.exe的服务创建的。该代理类尽量包含与Web服务商的Web方法一样多的方法，并且它结合了Web服务的公共接口 定义的任何自定义的数据类型。

这个操作不需要开发人员付出很大的代价。然而，开发人员显然要依赖于Visual Studio来生成代理类。如果能够直接把.wsdl文件放在应用程序的目录树的某个地方，并让ASP.NET处理其余的任务，这样不是更容易、更简单 吗？这正好是App_WebReferences文件夹要做的事情。

它识别那些用来描述所绑定的Web服务的.wsdl文件，并生成运行时代理类，以便ASP.NET页面能够以类型安全的方式 放置对Web服务的调用。App_WebReferences文件夹可以包含子文件夹。子文件夹的名称驱动最后所得到的代理类的命名空间，而WSDL文件 定义类名。例如，samples.wsdl文件和ProsAspNet20子文件夹将创建一个称为ProAspNet20.Samples的代理类。该动 态创建的程序集称为App_WebReferences.xxx.dll，其中xxx是一个随机的字符序列。