一个日期数组，其中可能有连续的日期，要格式化成特定形式的字符串，例如：2010-8-1，2010-8-3，2010-8-4，2010-8-5，2010-8-10格式化成字符串“8.1；8.3-8.5；8.10”，可以用如下的算法：

    private string GetFormatDateString()
    {
        List<DateTime> timeList = new List<DateTime>
        {
            new DateTime(2010,8,1),
            new DateTime(2010,8,3),
            new DateTime(2010,8,4),
            new DateTime(2010,8,5),
            new DateTime(2010,8,6),
            new DateTime(2010,8,7),
            new DateTime(2010,8,9),
            new DateTime(2010,8,11),
            new DateTime(2010,8,12)
        };
        string arr = "";
        int lastIndex = -1;
        for (int j = 0; j < timeList.Count; j++)
        {
            if (j > lastIndex)
            {
                int i = 1;
                while (timeList.Contains(timeList[j].AddDays(i)))
                {
                    i++;
                }
                if (i == 1)
                {
                    arr += timeList[j].Month + "." + timeList[j].Day + ";";
                    lastIndex = j;
                }
                else
                {
                    arr += timeList[j].Month + "." + timeList[j].Day + "-" + timeList[j + i - 1].Month + "." + timeList[j + i - 1].Day + ";";
                    lastIndex = j + i - 1;
                }
            }
        }
        arr = arr.TrimEnd(';');
        return arr;
    }

在.NET Framework中,内存中的资源(即所有二进制信息的集合)分为"托管资源"和"非托管资源".托管资源必须接受.NET Framework的CLR(通用语言运行时)的管理(诸如内存类型安全性检查),而非托管资源则不必接受.NET Framework的CLR管理. (了解更多区别请参阅.NET Framework或C#的高级编程资料)
  托管资源在.NET Framework中又分别存放在两种地方: "堆栈"和"托管堆"(以下简称"堆");规则是,所有的值类型(包括引用和对象实例)和引用类型的引用都存放在"堆栈"中,而所有引用所代表的对象实例都保存在堆中。
在C#中,释放托管资源是可以自动通过"垃圾回收器"完成的(注意,"垃圾回收"机制是.NET Framework的特性,而不是C#的),但具体来说,仍有些需要注意的地方:

1.值类型(包括引用和对象实例)和引用类型的引用其实是不需要什么"垃圾回收器"来释放内存的,因为当它们出了作用域后会自动释放所占内存(因为它们都保存在"堆栈"中,学过数据结构可知这是一种先进后出的结构);
2.只有引用类型的引用所指向的对象实例才保存在"堆"中,而堆因为是一个自由存储空间,所以它并没有像"堆栈"那样有生存期("堆栈"的元素弹出后就代 表生存期结束,也就代表释放了内存),并且非常要注意的是,"垃圾回收器"只对这块区域起作用;
3."垃圾回收器"也许并不像许多人想象的一样会立即执行(当堆中的资源需要释放时),而是在引用类型的引用被删除和它在"堆"中的对象实例被删除中间有 个间隔,为什么呢? 因为"垃圾回收器"的调用是比较消耗系统资源的,因此不可能经常被调用!
(当然,用户代码可以用方法System.GC.Collect()来强制执行"垃圾回收器")
4．有析构函数的对象需要垃圾收集器两次处理才能删除：第一次调用析构函数时，没有删除对象，第二次调用才真正删除对象。
5．由于垃圾收集器的工作方式，无法确定C#对象的析构函数何时执行。
6．可实现IDisposable接口的Dispose()来显示释放由对象使用的所有未托管资源。

7．垃圾收集器在释放了它能释放的所有对象后，就会压缩其他对象，把他们都移动回heap的端部，再次形成一个连续的块。   

导言
  垃圾回收(Garbage Collection)在.net中是一个很重要的机制. 本文将要谈到CLR4.0对垃圾回收做了哪些改进. 为了更好地理解这些改进, 本文也要介绍垃圾回收的历史.  这样我们对整个垃圾回收有一个大的印象. 这个大印象对于我们掌握.net架构是有帮助的.

关于垃圾回收
  在C++时代，我们需要自己来管理申请内存和释放内存. 于是有了new, delete关键字. 还有的一些内存申请和释放函数(malloc/free). C++程序必须很好地管理自己的内存, 不然就会造成内存泄漏(Memory leak). 在.net时代, 微软为开发人员提供了一个强有力的机制--垃圾回收. 垃圾回收机制是CLR的一部分, 我们不用操心内存何时释放, 我们可以花更多精力关注应用程序的业务逻辑. CLR里面的垃圾回收机制用一定的算法判断某些内存程序不再使用，回收这些内存并交给我们的程序再使用.

垃圾回收的功能
  用来管理托管资源和非托管资源所占用的内存分配和释放。

  寻找不再使用的对象，释放其占用的内存, 以及释放非托管资源所占用的内存。

  垃圾回收器释放内存之后, 出现了内存碎片, 垃圾回收器移动一些对象, 以得到整块的内存，同时所有的对象引用都将被调整为指向对象新的存储位置。

下面我们来看看CLR是如何管理托管资源的。

托管堆和托管栈
  .net CLR在运行我们的程序时，在内存中开辟了两块地方作不同的用处--托管栈和托管堆. 托管栈用来存放局部变量, 跟踪程序调用与返回. 托管堆用来存放引用类型. 引用类型总是存放于托管堆. 值类型通常是放在托管栈上面的. 如果一个值类型是一个引用类型的一部分，则此值类型随该引用类型存放于托管堆中. 哪些东西是值类型? 就是定义于System.ValueType之下的这些类型:

bool byte char decimal double enum float int long sbyte short struct uint ulong ushort

  什么是引用类型呢? 只要用class, interface, delegate, object, string声明的类型, 就是引用类型. 

我们定义一个局部变量, 其类型是引用类型. 当我们给它赋一个值, 如下例:

private void MyMethod()
{
   MyType  myType = new MyType();
   myType.DoSomeThing();
}
  在此例中, myType 是局部变量, new实例化出来的对象存储于托管堆, 而myType变量存储于托管栈. 在托管栈的myType变量存储了一个指向托管堆上new实例化出来对象的引用. CLR运行此方法时, 将托管栈指针移动, 为局部变量myType分配空间, 当执行new时, CLR先查看托管堆是否有足够空间, 足够的话就只是简单地移动下托管堆的指针, 来为MyType对象分配空间, 如果托管堆没有足够空间, 会引起垃圾收集器工作. CLR在分配空间之前，知道所有类型的元数据，所以能知道每个类型的大小, 即占用空间的大小.

  当CLR完成MyMethod方法的执行时, 托管栈上的myType局部变量被立即删除, 但是托管堆上的MyType对象却不一定马上删除. 这取决于垃圾收集器的触发条件.后面要介绍此触发条件。

注意：这里强调了，当对象的作用域结束后，他的引用由于在堆栈中，所以立刻被删除了，但是对象实例本身在托管堆中，因此不会立刻删除，而是等待的垃圾回收机制的运行。

上面我们了解了CLR如何管理托管资源. 下面我们来看垃圾收集器如何寻找不再使用的托管对象，并释放其占用的内存.

垃圾收集器如何寻找不再使用的托管对象，并释放其占用的内存
  前面我们了解了CLR如何管理托管栈上的对象.按照先进后出原则即可比较容易地管理托管栈的内存. 托管堆的管理比托管栈的管理复杂多了.下面所谈都是针对托管堆的管理.

根
  垃圾收集器寻找不再使用的托管对象时, 其判断依据是当一个对象不再有引用指向它, 就说明此对象是可以释放了. 一些复杂的情况下可以出现一个对象指向第二个对象,第二个对象指向第三个对象,…就象一个链表. 那么, 垃圾收集器从哪里开始查找不再使用的托管对象呢? 以刚才所说的链表为例, 显然是应该从链表的开头开始查找. 那么，在链表开头的是些什么东东呢?

  是局部变量, 全局变量, 静态变量, 指向托管堆的CPU寄存器. 在CLR中，它们被称之为根.

  有了开始点, 垃圾收集器接下来怎么做呢?

创建一个图, 一个描述对象间引用关系的图.
  垃圾收集器首先假定所有在托管堆里面的对象都是不可到达的(或者说没有被引用的,不再需要的), 然后从根上的那些变量开始, 针对每一个根上的变量, 找出其引用的托管堆上的对象, 将找到的对象加入这个图, 然后再沿着这个对象往下找，看看它有没有引用另外一个对象, 有的话，继续将找到的对象加入图中,如果没有的话, 就说明这条链已经找到尾部了. 垃圾收集器就去从根上的另外一个变量开始找, 直到根上的所有变量都找过了, 然后垃圾收集器才停止查找. 值得一提的是, 在查找过程中, 垃圾收集器有些小的优化, 如: 由于对象间的引用关系可能是比较复杂的, 所以有可能找到一个对象, 而此对象已经加入图了, 那么垃圾收集器就不再在此条链上继续查找, 转去其他的链上继续找. 这样对垃圾收集器的性能有所改善.

  垃圾收集器建好这个图之后, 剩下那些没有在这个图中的对象就是不再需要的. 垃圾收集器就可以回收它们占用的空间.

内存释放和压缩
  创建对象引用图之后，垃圾回收器将那些没有在这个图中的对象(即不再需要的对象)释放。释放内存之后, 出现了内存碎片, 垃圾回收器扫描托管堆，找到连续的内存块，然后移动未回收的对象到更低的地址, 以得到整块的内存，同时所有的对象引用都将被调整为指向对象新的存储位置。这就象一个夯实的动作。也就是说，一个对象即使没有被清除，由于内存压缩，导致他的引用位置发生变化。

  下面要说到的是代的概念。代概念的引入是为了提高垃圾收集器的整体性能。

代

  请想一想如果垃圾收集器每次总是扫描所有托管堆中的对象，对性能会有什么影响。会不会很慢？是的。微软因此引入了代的概念。

为什么代的概念可以提高垃圾收集器的性能？因为微软是基于对大量编程实践的科学估计，做了一些假定而这些假定符合绝大多数的编程实践:

越新的对象，其生命周期越短。

越老的对象，其生命周越长。

新对象之间通常有强的关系并被同时访问。

压缩一部分堆比压缩整个堆快。

有了代的概念，垃圾回收活动就可以大部分局限于一个较小的区域来进行。这样就对垃圾回收的性能有所提高。

让我们来看垃圾收集器具体是怎么实现代的:

第0代：新建对象和从未经过垃圾回收对象的集合  

第1代：在第0代收集活动中未回收的对象集合 

第2代：在第1和第2代中未回收的对象集合, 即垃圾收集器最高只支持到第2代, 如果某个对象在第2代的回收活动中留下来，它仍呆在第2代的内存中。

当程序刚开始运行，垃圾收集器分配为每一代分配了一定的内存，这些内存的初始大小由.net framework的策略决定。垃圾收集器记录了这三代的内存起始地址和大小。这三代的内存是连接在一起的。第2代的内存在第1代内存之下，第1代内存在第0代内存之下。应用程序分配新的托管对象总是从第0代中分配。如果第0代中内存足够，CLR就很简单快速地移动一下指针，完成内存的分配。这是很快速的。当第0代内存不足以容纳新的对象时，就触发垃圾收集器工作，来回收第0代中不再需要的对象，当回收完毕，垃圾收集器就夯实第0代中没有回收的对象至低的地址，同时移动指针至空闲空间的开始地址(同时按照移动后的地址去更新那些相关引用)，此时第0代就空了，因为那些在第0代中没有回收的对象都移到了第1代。

  当只对第0代进行收集时，所发生的就是部分收集。这与之前所说的全部收集有所区别(因为代的引入)。对第0代收集时，同样是从根开始找那些正引用的对象，但接下来的步骤有所不同。当垃圾收集器找到一个指向第1代或者第2代地址的根，垃圾收集器就忽略此根，继续找其他根，如果找到一个指向第0代对象的根，就将此对象加入图。这样就可以只处理第0代内存中的垃圾。这样做有个先决条件，就是应用程序此前没有去写第1代和第2代的内存，没有让第1代或者第2代中某个对象指向第0代的内存。但是实际中应用程序是有可能写第1代或者第2代的内存的。针对这种情况，CLR有专门的数据结构(Card table)来标志应用程序是否曾经写第1代或者第2代的内存。如果在此次对第0代进行收集之前，应用程序写过第1代或者第2代的内存，那些被Card Table登记的对象(在第1代或者第2代)将也要在此次对第0代收集时作为根。这样，才可以正确地对第0代进行收集。

  以上说到了第0代收集发生的一个条件，即第0代没有足够内存去容纳新对象。执行GC.Collect()也会触发对第0代的收集。另外，垃圾收集器还为每一代都维护着一个监视阀值。第0代内存达到这个第0代的阀值时也会触发对第0代的收集。对第1代的收集发生在执行GC.Collect(1)或者第1代内存达到第1代的阀值时。第2代也有类似的触发条件。当第1代收集时，第0代也需要收集。当第2代收集时，第1和第0代也需要收集。在第n代收集之后仍然存留下来的对象将被转移到第n+1代的内存中，如果n=2, 那么存留下来的对象还将留在第2代中。

对象结束

对象结束机制是程序员忘记用Close或者Dispose等方法清理申请的资源时的一个保证措施。如下的一个类，当一个此类的实例创建时，在第0代中分配内存，同时此对象的引用要被加入到一个由CLR维护的结束队列中去。

view plaincopy to clipboardprint?
public class BaseObj   
{      
public BaseObj()   
{   
}      
protected override void Finalize()   
{          
// Perform resource cleanup code here...          
// Example: Close file/Close network connection        Console.WriteLine("In Finalize.");     
}  
} 
public class BaseObj
{   
public BaseObj()
{
}   
protected override void Finalize()
{       
// Perform resource cleanup code here...       
// Example: Close file/Close network connection        Console.WriteLine("In Finalize.");  
}
}

当此对象成为垃圾时，垃圾收集器将其引用从结束队列移到待结束队列中，同时此对象会被加入引用关系图。一个独立运行的CLR线程将一个个从待结束队列(Jeffrey Richter称之为Freachable queue)取出对象，执行其Finalize方法以清理资源。因此，此对象不会马上被垃圾收集器回收。只有当此对象的Finalize方法被执行完毕后，其引用才会从待结束队列中移除。等下一轮回收时，垃圾回收器才会将其回收。

  GC类有两个公共静态方法GC.ReRegisterForFinalize和GC.SuppressFinalize大家也许想了解一下，ReRegisterForFinalize是将指向对象的引用添加到结束队列中(即表明此对象需要结束)，SuppressFinalize是将结束队列中该对象的引用移除，CLR将不再会执行其Finalize方法。

  因为有Finalize方法的对象在new时就自动会加入结束队列中，所以ReRegisterForFinalize可以用的场合比较少。ReRegisterForFinalize比较典型的是配合重生(Resurrection)的场合来用。重生指的是在Finalize方法中让根又重新指向此对象。那么此对象又成了可到达的对象，不会被垃圾收集器收集，但是此对象的引用未被加入结束队列中。所以此处需要用ReRegisterForFinalize方法来将对象的引用添加到结束队列中。因为重生本身在现实应用中就很少见，所以ReRegisterForFinalize也将比较少用到。

  相比之下，SuppressFinalize更常用些。SuppressFinalize用于同时实现了Finalize方法和Dispose()方法来释放资源的情况下。在Dispose()方法中调用GC.SuppressFinalize(this)，那么CLR就不会执行Finalize方法。Finalize方法是程序员忘记用Close或者Dispose等方法清理资源时的一个保证措施。如果程序员记得调用Dispose()，那么就会不执行Finalize()来再次释放资源；如果程序员忘记调用Dispose(), Finalize方法将是最后一个保证资源释放的措施。这样做不失为一种双保险的方案。

  对象结束机制对垃圾收集器的性能影响比较大，同时CLR难以保证调用Finalize方法的时间和次序。因此，尽量不要用对象结束机制，而采用自定义的方法或者名为Close, Dispose的方法来清理资源。可以考虑实现IDisposable接口并为Dispose方法写好清理资源的方法体。

大对象堆

  大对象堆专用于存放大于85000字节的对象。初始的大对象内存区域堆通常在第0代内存之上，并且与第0代内存不邻接。第0,第1和第2代合起来称为小对象堆。CLR分配一个新的对象时，如果其大小小于85000字节，就在第0代中分配，如果其大小大于等于85000自己，就在大对象堆中分配。

  因为大对象的尺寸比较大，收集时成本比较高，所以对大对象的收集是在第2代收集时。大对象的收集也是从根开始查找可到达对象，那些不可到达的大对象就可回收。垃圾收集器回收了大对象后，不会对大对象堆进行夯实操作(毕竟移动大对象成本较高)，而是用一个空闲对象表的数据结构来登记哪些对象的空间可以再利用，其中两个相邻的大对象回收将在空闲对象表中作为一个对象对待。空闲对象表登记的空间将可以再分配新的大对象。

  大对象的分配，回收的成本都较小对象高，因此在实践中最好避免很快地分配大对象又很快回收，可以考虑如何分配一个大对象池，重复利用这个大对象池，而不频繁地回收。

弱引用
  弱引用是相对强引用来说的。强引用指的是根有一个指针指向对象。弱引用是通过对强引用加以弱化而得到的。这个弱化的手段就是用System.WeakReference类。所以精确地说，强引用指的是根有一个非WeakReference类型的指针指向对象，而弱引用就是根有一个WeakReference类型的指针指向对象。垃圾收集器看到一个WeakReference类型的根指向某个对象，就会特别处理。所以在垃圾收集器创建对象引用关系图的时候，如果遇到一个弱引用指针，那么垃圾收集器就不会将其加入图中。如果一个对象只有弱引用指向它，那么垃圾收集器可以收集此对象。一旦将一个强引用加到对象上，不管对象有没有弱引用，对象都不可回收。

  垃圾收集器对WeakReference类的特别处理从new操作就开始。通常的类，只要new操作，就会从托管堆分配空间，而WeakReference类的new操作不是这样做的。我们先来看WeakReference类的构造函数：

WeakReference(Object target);

WeakReference(Object target, Boolean trackResurrection);

此二构造函数都需要一个对象的引用，第二个构造函数还需要一个布尔值参数来表示我们是否需要跟踪对象的重生。此参数的意义后文会交代。

假设我们有两个类MyClass和MyAnotherClass，都有Finalize方法。我们声明两个对象：

MyClass myObject = new MyClass();

MyAnotherClass myAnotherObject = new MyAnotherClass();

当我们用这样的代码声明一个弱引用对象: WeakReference myShortWeakReferenceObject = new WeakReference( myObject );

垃圾收集器内部有一个短弱引用表，用这样声明的弱引用对象将不会在托管堆中分配空间，而是在短弱引用表中分配一个槽。此槽中记录对myObject的引用。New操作将此槽的地址返回给myShortWeakReferenceObject变量。

如果我们用这样的代码声明一个弱引用对象(我们要跟踪该对象的重生): WeakReference myLongWeakReferenceObject = new WeakReference( myAnotherObject, true );

When we use such a snippet of code to declare a weak reference object(We need to track resurrection of the object): WeakReference myLongWeakReferenceObject = new WeakReference( myAnotherObject, true );

垃圾收集器内部有一个长弱引用表，用这样声明的弱引用对象将不会在托管堆中分配空间，而是在长弱引用表中分配一个槽。此槽中记录对myAnotherObject的引用。New操作将此槽的地址返回给myLongWeakReferenceObject变量。

垃圾收集器此时的收集流程是这样的:

1. 垃圾收集器建立对象引用图，来找到所有的可到达对象。前文已经说过如何建立图。特别的地方是，如果遇到非WeakReference指针，就加入图，如果遇到WeakReference指针，就不加入图。这样图就建好了。

2. 垃圾收集器扫描短弱引用表。如果一个指针指向一个不在图中的对象，那么此对象就是一个不可到达的对象，垃圾收集器就将短弱引用表相应的槽置空。

3. 垃圾收集器扫描结束队列。如果队列中一个指针指向一个不在图中的对象，此指针将被从结束队列移到待结束队列，同时此对象被加入引用关系图中，因为此时此对象是Finalize可到达的。

4. 垃圾收集器扫描长弱引用表。如果一个指针指向一个不在图中的对象(注意此时图中已包含Finalize可到达的对象)，那么此对象就是一个不可到达的对象，垃圾收集器就将长弱引用表相应的槽置空。

5. 垃圾收集器夯实(压缩)托管堆。
短弱引用不跟踪重生。即垃圾收集器发现一个对象为不可到达就立即将短弱引用表相应的槽置空。如果该对象有Finalize方法，并且Finalize方法还没有执行，所以该对象就还存在。如果应用程序访问弱引用对象的Target属性，即使该对象还存在，也会得到null。

  长弱引用跟踪重生。即垃圾收集器发现一个对象是Finalize可到达的对象，就不将相应的槽置空。因为Finalize方法还没有执行，所以该对象就还存在。如果应用程序访问弱引用对象的Target属性，可以得到该对象；但是如果Finalize方法已经被执行，就表明该对象没有重生。

  按照上面的例子，如果执行如下代码会发生什么呢？

view plaincopy to clipboardprint?
//File: MyClass.cs  
using System;  
using System.Collections.Generic;  
using System.Text;  
namespace ConsoleApplication2  
{  
    class MyClass  
    {  
        ~MyClass()  
        {  
            Console.WriteLine("In MyClass destructor+++++++++++++++++++++++++++");  
        }  
    }  
}//File: MyAnotherClass.cs  
using System;  
using System.Collections.Generic;  
using System.Text;  
namespace ConsoleApplication2  
{  
    public class MyAnotherClass  
    {  
        ~MyAnotherClass()  
        {  
            Console.WriteLine("In MyAnotherClass destructor___________________________________");  
        }  
    }  
}//File: Program.cs  
using System;  
using System.Collections.Generic;  
using System.Text;  
namespace ConsoleApplication2  
{  
    class Program  
    {  
        static void Main(string[] args)  
        {  
            MyClass myClass = new MyClass();  
            MyAnotherClass myAnotherClass = new MyAnotherClass();  
            WeakReference myShortWeakReferenceObject = new WeakReference(myClass);  
            WeakReference myLongWeakReferenceObject = new WeakReference(myAnotherClass, true);  
            Console.WriteLine("Release managed resources by setting locals to null.");  
            myClass = null;  
            myAnotherClass = null;  
            Console.WriteLine("Check whether the objects are still alive.");  
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");  
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");  
            Console.WriteLine("Programmatically cause GC.");  
            GC.Collect();  
            Console.WriteLine("Wait for GC runs the finalization methods.");  
            GC.WaitForPendingFinalizers();  
            //Check whether the objects are still alive.  
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");  
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");  
            Console.WriteLine("Programmatically cause GC again. Let's see what will happen this time.");  
            GC.Collect();  
            //Check whether the objects are still alive.  
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");  
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");  
            myAnotherClass = (MyAnotherClass)myLongWeakReferenceObject.Target;  
            Console.ReadLine();  
        }  
        static void CheckStatus(WeakReference weakObject, string strLocalVariableName, string strWeakObjectName)  
        {  
            Console.WriteLine(strLocalVariableName + (weakObject.IsAlive ? " is still alive." : " is not alive."));  
            Console.WriteLine(strWeakObjectName + (weakObject.Target != null ? ".Target is not null." : ".Target is null."));  
            Console.WriteLine();  
        }  
    }  
} 
//File: MyClass.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    class MyClass
    {
        ~MyClass()
        {
            Console.WriteLine("In MyClass destructor+++++++++++++++++++++++++++");
        }
    }
}//File: MyAnotherClass.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    public class MyAnotherClass
    {
        ~MyAnotherClass()
        {
            Console.WriteLine("In MyAnotherClass destructor___________________________________");
        }
    }
}//File: Program.cs
using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            MyClass myClass = new MyClass();
            MyAnotherClass myAnotherClass = new MyAnotherClass();
            WeakReference myShortWeakReferenceObject = new WeakReference(myClass);
            WeakReference myLongWeakReferenceObject = new WeakReference(myAnotherClass, true);
            Console.WriteLine("Release managed resources by setting locals to null.");
            myClass = null;
            myAnotherClass = null;

            Console.WriteLine("Check whether the objects are still alive.");
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");

            Console.WriteLine("Programmatically cause GC.");
            GC.Collect();

            Console.WriteLine("Wait for GC runs the finalization methods.");
            GC.WaitForPendingFinalizers();

            //Check whether the objects are still alive.
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");

            Console.WriteLine("Programmatically cause GC again. Let's see what will happen this time.");
            GC.Collect();

            //Check whether the objects are still alive.
            CheckStatus(myShortWeakReferenceObject, "myClass ", "myShortWeakReferenceObject");
            CheckStatus(myLongWeakReferenceObject, "myAnotherClass", "myLongWeakReferenceObject");

            myAnotherClass = (MyAnotherClass)myLongWeakReferenceObject.Target;

            Console.ReadLine();
        }

        static void CheckStatus(WeakReference weakObject, string strLocalVariableName, string strWeakObjectName)
        {
            Console.WriteLine(strLocalVariableName + (weakObject.IsAlive ? " is still alive." : " is not alive."));
            Console.WriteLine(strWeakObjectName + (weakObject.Target != null ? ".Target is not null." : ".Target is null."));
            Console.WriteLine();
        }
    }
}

请大家想一想如果MyAnotherClass类没有Finalize方法呢?

或者:如果我们注释掉这行: GC.WaitForPendingFinalizers();, 试着多执行此代码多次, 看看每次会输出什么呢？是不是Finzalization方法被执行的时机不确定?

弱引用是为大对象准备的。在实际当中，如果不用弱引用，只用强引用，则用过了该大对象，然后将强引用置null，让GC可以回收它，但是没过多久我们又需要这个大对象了，但是已经没有办法找回原来的对象，只好重新创建实例，这样就浪费了创建实例所需的计算资源；而如果不置null，就会占用很多内存资源。对于这种情况，我们可以创建一个这个大对象的弱引用，这样在内存不够时将强引用置null，让GC可以回收，而在没有被GC回收前，如果我们短时间内还需要该大对象，我们还可以再次找回该对象，不用再重新创建实例。是不是节省了一些开销？

垃圾收集的一般流程

以下是垃圾收集的一般流程，受应用场景(如服务器应用，并发和非并发)影响，具体的垃圾回收流程可能有所不同。

1. 挂起.net应用的所有线程

2. 找到可回收的对象

3. 回收可回收的对象并压缩托管堆

4. 继续.net应用的所有线程

垃圾收集的模式

CLR4.0之前，一共有三种模式的GC，分别针对不同类型的应用程序而优化：Server版非并发GC, Workstation版并发GC, 和Workstation版非并发GC.

Server GC - Non Concurrent
Server GC是针对服务器应用而进行优化的，目的是为了保证其高吞吐量和高的规模可扩展性。

Server GC 为每一个处理器分配一个托管堆和一个GC线程。各GC线程独立工作在各自的堆上，这样最大程度地减少了锁，从而保证了此种情况下的高效。这些GC线程是非并发的（第0代，第1代，第2代都是非并发的，即在收集时都要停止所有应用程序的线程，直到收集结束）。同时这些GC线程是专门的线程，不同于应用程序的线程。

实际的Server GC工作流程是这样的:

1. 应用程序的线程在其托管堆上分配空间

2. 其托管堆没有更多空间来分配托管对象

3. 于是触发一个事件，让GC线程来做收集，并等待GC线程完成收集

4. GC线程运行，完成收集并发出完成事件(在GC线程运行期间，应用程序线程是暂停的)

5. 应用程序的线程继续运行

这种类型的GC只有在多处理器的机器上可见，如果你在单处理器上的设置这种模式，那你将得到workstation版本非并发的GC。

Asp.net的应用在多cpu的机器上默认使用这种模式，还有其他一些类型的服务器应用也在多cpu的机器上使用这种模式。例如如果你想在Windows服务上使用server GC模式，你可以在应用程序配置文件中做如下设置：

<configuration>
<runtime>
   <gcServer enabled="true" />
</runtime>
</configuration>

Workstation GC – Concurrent
Winform应用程序和Windows services 服务程序默认采用这种模式。

这种模式是针对交互式应用程序优化的，这种程序要求应用程序不能暂停，即使是一个相对很短暂的时间也是不行的。因为暂停进程会让用户界面闪烁或者当点击按钮的时候感觉应用程序没有响应。

在这种模式下，第0代和第1代的收集仍然是要暂停应用程序的线程直到收集完毕，因为第0代和第1代的收集速度很快，所以没有必要去做并行。所谓的并发是在需要第2代收集时，我们可以选择让第2代收集并行地执行或者暂停应用程序的所有线程直到收集结束。如果我们没有做选择，那么默认的就是第2代收集是并行的。

有一个专门的GC线程来并行地收集垃圾。在第2代收集时，用更多CPU周期和堆内存来换取更短的用户界面停顿时间。

并行收集仍然需要在收集过程中暂停应用程序多次，但这几次暂停相对较短，对UI线程影响较小。应用程序线程在并行收集进行中可以同时分配对象。这就要求第0代有较大的空间和较高的触发Gen 0收集的阀值。如果应用程序用完第0代的内存，而并行收集还没有进行完毕，那么应用程序不得不暂停下来，等待并行收集的完成。

如果我们要做选择，让应用程序在并行模式下运行，可以在应用程序的config文件中写上:

<configuration>

<runtime>

<gcServer enabled=“true"/>

</runtime>

</configuration>

注: Jeffrey Richter似乎在其书<<CLR via c#>>中说concurrent GC只有在多CPU机器上有。但是经过Mark的调查，实际上concurrent GC在单CPU上也有。

这种模式与Server GC类似，推荐为那种运行在单个cpu机器上服务类型的应用程序使用。与Server GC不同的是：其收集线程即等同于应用程序线程。这是这种模式的工作流程：

1) 应用程序线程在堆上分配对象

2) 第0代没有足够空间It

3) 在同一线程上引发垃圾收集

4) 垃圾收集器调用SuspendEE函数暂停应用程序线程

5) GC做收集工作

6) GC调用RestartEE来继续应用程序的线程GC

7) 应用程序的线程继续运行

可以修改应用程序的配置来把 concurrency 关闭。

<configuration>
<runtime>
   <gcConcurrent enabled="false" />
</runtime>
</configuration>

下面是三种模式的对比表:

以上我们说到了CLR 4.0以前垃圾收集的大部分方面。 掌握前面的知识有助于理解CLR 4.0所带来的变化。

CLR 2.0以后GC有哪些变化呢?CLR V4.0带来的后台垃圾收集

前面我们已经提到已经有了并发垃圾收集。后台垃圾收集是来替代并发垃圾收集。后台垃圾收集是并发垃圾收集的进化。

当应用程序的活动量不大(包括分配和修改引用)并且堆不太大时，并发垃圾收集工作得好。由并发垃圾收集带来的延迟是可接受的。但是当人们编写更大的应用程序，需要用到更大的堆，这时由并发收集带来的延迟就变得不可接受。

后台垃圾收集的显著改进是：在后台垃圾收集进行中，如果需要的话，我们可以做短的垃圾收集(第0代和第1代收集)。与并发垃圾收集类似，后台垃圾收集也是只有在全部垃圾收集时才有。并且短的垃圾收集(第0代和第1代收集)总是按阻断方式进行垃圾收集(暂停应用程序)。后台垃圾收集在一个专门的线程上运行。那些与后台垃圾收集同时进行的短垃圾收集(第0代和第1代收集)被称为前台垃圾收集。

于是，当后台垃圾收集正进行中而第0代空间不足，就会触发一个第0代垃圾收集(有可能升级成第1代收集，取决于垃圾收集器的内部决策)。后台垃圾收集线程会经常检查安全点(比如前台垃圾收集发生)。当有前台垃圾收集时，后台垃圾收集会自己暂停并让前台垃圾收集可以开始开始工作。在前台垃圾收集完成之后，后台垃圾时线程和应用程序的线程就继续它们的工作。

后台垃圾收集不仅在较低的代将无用的对象清除，同时它提高了对象停留在短生命周期段的限制--如果后台垃圾收集进行中需要扩展堆，我们可以在第1代收集时这样做。而这在CLR1.0和CLR2.0只有在第2代收集时才会发生。

后台垃圾收集比并发收集的好处体现在：在后台收集进行中，应用程序耗尽了第0代的空间，如果是并发收集，应用程序必须暂停以等待并发收集完成。而现在不同了，可以用前台收集对第0代或者第1代进行收集。于是就不必等待。同时，如果需要，可以在第1代收集就扩展堆(增加内存段)，而不必等到第2代收集。这减少了让UI应用程序暂停的机会。

我们通过并行地做更多事情改进了后台垃圾收集的性能，所以需要暂停应用程序线程的时间更短。我们现在没有在CLRV4.0中为Server GC提供后台垃圾收集。那将是后续的工作。

.net 3.5 SP1中的全部收集通知机制Full GC notification in .net 3.5 SP1
全部收集通知机制是为担负大量请求的服务器应用准备的。因为存在一些情况，CLR的全部收集会带来较大的延迟，从而影响服务器应用的性能，导致用户请求超时。针对这种情况，全部收集通知机制应运而生。当一个全垃圾收集将要开始时，你会得到通知并可以采取相应动作，如将请求导向别的服务器。

.net 3.5 SP1的GC类增加了几个方法:

GC.RegisterForFullGCNotification

GC.WaitForFullGCApproach

GC.WaitForFullGCComplete

GC.CancelFullGCNotification

并在System命名空间下增加了一个枚举

GCNotificationStatus

这个GC.RegisterForFullGCNotification 用来注册当前应用将要接收全部垃圾收集的通知。当一个全部垃圾收集将要发生时，注册了的应用程序就可收到通知。同时，当一个全部垃圾收集完成时，注册了的程序也会收到通知。这是GC.RegisterForFullGCNotification 的申明方式:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static void RegisterForFullGCNotification(
    int maxGenerationThreshold,
    int largeObjectHeapThreshold
)

maxGenerationThreshold是1-99之间的数.指的是第2代中存活的对象个数达到这个阀值就要通知. largeObjectHeapThreshold也是1-99之间的数.指的是大对象堆中分配的对象个数达到这个阀值就要通知.

WaitForFullGCApproach用来获得垃圾收集器是否将要进行全部垃圾收集. 它的声明是这样的:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCApproach()或者[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCApproach(
    int millisecondsTimeout
)

第2个调用方式可以带一个等待时间, 单位是毫秒. 其返回的是枚举GCNotificationStatus, 如果是GCNotificationStatus.Succeeded, 那么我们就可以将请求导向其他服务器.与WaitForFullGCApproach类似的, WaitForFullGCComplete用来获得垃圾收集器是否已经完成全部垃圾收集, 它的声明是这样的:

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCComplete()或者

[PermissionSetAttribute(SecurityAction.LinkDemand, Name = "FullTrust")]
public static GCNotificationStatus WaitForFullGCComplete(
    int millisecondsTimeout
)

第2个调用方式可以带一个等待时间, 单位是毫秒. 其返回的是枚举GCNotificationStatus, 如果是GCNotificationStatus.Succeeded, 那么我们就可以将此服务器重新声明可以接受外界的请求.

WaitForFullGCApproach和WaitForFullGCComplete设计时就是要一起使用的。如果只使用一个而不使用另一个就会导致不可知的结果。

GC.CancelFullGCNotification是用来将已经注册的垃圾收集通知取消. 与GC.RegisterForFullGCNotification 一起成对配合使用.

通常的使用方法是这样的:

1.首先在主线程调用GC.RegisterForFullGCNotification 来准备收获通知

2.启动一个值守线程, 在值守线程中调用WaitForFullGCApproach和WaitForFullGCComplete来获取当前GC状态, 如果是将要进行全部垃圾收集，就做相应处理，如将请求导向其他服务器。如果是全部垃圾收集完毕，则可做相应处理, 如将此服务器标记为可接受请求.值守线程中需要不断循环来轮循GC状态.

3.当主线程将要结束, 调用GC.CancelFullGCNotification并发消息通知值守线程, 值守线程退出循环，结束.

4.主线程退出

对于asp.net应用, 可以在Application_Start中调用GC.RegisterForFullGCNotification并启动一个值守线程. 同时可以在Application_End中通知值守线程结束.

全部垃圾收集通知机制的典型用途就是在多服务器的场景.用NLB(Network load balance)搭建的Web Farm或者硬件load balance的多服务器场景. 一个比较复杂的场景是每个服务器上还有web garden设置.

注意事项: 全部垃圾收集通知机制只有在非并发模式时才可用. WinForm和Console应用都是默认为并发模式. 例如msdn上的那个例子程序，就需要在程序的app.config中加上

<configuration>
<runtime>
   <gcConcurrent enabled="false" />
</runtime>
</configuration>

原文链接：http://blog.csdn.net/lerit/archive/2009/08/16/4451287.aspx

      ASP.NET 页运行时，此页将经历一个生命周期，在生命周期中将执行一系列处理步骤。这些步骤包括初始化、实例化控件、还原和维护状态、运行事件处理程序代码以及进行呈现。了解页生命周期非常重要，因为这样做我们就能在生命周期的合适阶段编写代码，以达到预期效果。此外，如果要开发自定义控件，就必须熟悉页生命周期，以便正确进行控件初始化，使用视图状态数据填充控件属性以及运行任何控件行为代码。（控件的生命周期基于页的生命周期，但是页引发的控件事件比单独的 ASP.NET 页中可用的事件多。）
      一般来说，页要经历以下的各个阶段。除了页生命周期阶段以外，在请求前后还存在应用程序阶段，但是这些阶段并不特定于页。可以参考：

• 页请求

        页请求发生在页生命周期开始之前。用户请求页时，ASP.NET 将确定是否需要分析和编译页（从而开始页的生命周期），或者是否可以在不运行页的情况下发送页的缓存版本以进行响应。

• 开始

       在开始阶段，将设置页属性，如 Request 和 Response。在此阶段，页还将确定请求是回发请求还是新请求，并设置 IsPostBack 属性。此外，在开始阶段期间，还将设置页的 UICulture 属性。

      页初始化
       页初始化期间，可以使用页中的控件，并将设置每个控件的 UniqueID 属性。此外，任何主题都将应用于页。如果当前请求是回发请求，则回发数据尚未加载，并且控件属性值尚未还原为视图状态中的值。

      加载
       加载期间，如果当前请求是回发请求，则将使用从视图状态和控件状态恢复的信息加载控件属性。

      验证
       在验证期间，将调用所有验证程序控件的 Validate 方法，此方法将设置各个验证程序控件和页的 IsValid 属性。
      
      回发事件处理
       如果请求是回发请求，则将调用所有事件处理程序。

      呈现
      在呈现之前，会针对该页和所有控件保存视图状态。在呈现阶段中，页会针对每个控件调用 Render 方法，它会提供一个文本编写器，用于将控件的输出写入页的 Response 属性的 OutputStream 中。

      卸载
      完全呈现页并已将页发送至客户端、准备丢弃该页后，将调用卸载。此时，将卸载页属性（如 Response 和 Request）并执行清理。

      在页生命周期的每个阶段中，页将引发可运行代码进行处理的事件。对于控件事件，通过以声明方式使用属性（如 onclick）或以使用代码的方式，均可将事件处理程序绑定到事件。

      页还支持自动事件连接，即，ASP.NET 将查找具有特定名称的方法，并在引发了特定事件时自动运行这些方法。如果 @ Page 指令的 AutoEventWireup 属性设置为 true（或者未定义该属性，因为该属性默认为 true），页事件将自动绑定至使用 Page_事件的命名约定的方法（如 Page_Load 和 Page_Init）。

   最常用的页生命周期事件    
       PreInit

        使用该事件来执行下列操作：

• 检查 IsPostBack 属性来确定是不是第一次处理该页。

• 创建或重新创建动态控件。

• 动态设置主控页。

• 动态设置 Theme 属性。

• 读取或设置配置文件属性值。

       Init

      在所有控件都已初始化且已应用所有外观设置后引发。使用该事件来读取或初始化控件属性。

      InitComplete 
      由 Page 对象引发。使用该事件来处理要求先完成所有初始化工作的任务。
      
      PreLoad
      如果需要在 Load 事件之前对页或控件执行处理，请使用该事件。

      在 Page 引发该事件后，它会为自身和所有控件加载视图状态，然后会处理 Request 实例包括的任何回发数据。

      Load
      Page 在 Page 上调用 OnLoad 事件方法，然后以递归方式对每个子控件执行相同操作，如此循环往复，直到加载完本页和所有控件为止。使用 OnLoad 事件方法来设置控件中的属性并建立数据库连接。
      
      控件事件
      使用这些事件来处理特定控件事件，如 Button 控件的 Click 事件或 TextBox 控件的 TextChanged 事件。

      LoadComplete
      对需要加载页上的所有其他控件的任务使用该事件。

      PreRender
      在该事件发生前：

• Page 对象会针对每个控件和页调用 EnsureChildControls。

• 设置了 DataSourceID 属性的每个数据绑定控件会调用 DataBind 方法。

      页上的每个控件都会发生 PreRender 事件。使用该事件对页或其控件的内容进行最后更改。

      SaveStateComplete
      在该事件发生前，已针对页和所有控件保存了 ViewState。将忽略此时对页或控件进行的任何更改。

使用该事件执行满足以下条件的任务：要求已经保存了视图状态，但未对控件进行任何更改。

      Render
      这不是事件；在处理的这个阶段，Page 对象会在每个控件上调用此方法。所有 ASP.NET Web 服务器控件都有一个用于写出发送给浏览器的控件标记的 Render 方法。

      如果创建自定义控件，通常要覆盖此方法以输出控件的标记。不过，如果自定义控件只合并标准的 ASP.NET Web 服务器控件，不合并自定义标记，则不需要覆盖 Render 方法。

      用户控件（.ascx 文件）自动合并呈现，因此不需要在代码中显式呈现该控件。

      Unload
      该事件首先针对每个控件发生，继而针对该页发生。在控件中，使用该事件对特定控件执行最后清理，如关闭控件特定数据库连接。

      对于页自身，使用该事件来执行最后清理工作，如：关闭打开的文件和数据库连接，或完成日志记录或其他请求特定任务。

      IIS 7.0 和 IIS 6.0 的处理阶段之间的主要区别在于 ASP.NET 如何与 IIS 服务器集成。在 IIS 6.0 中，有两个请求处理管道。一个管道用于本机代码 ISAPI 筛选器和扩展组件。另一个管道用于托管代码应用程序组件，如 ASP.NET。在 IIS 7.0 中，ASP.NET 运行库与 Web 服务器集成，这样就有了一个针对所有请求的统一的请求处理管道。


在 IIS 7.0 集成模式下运行的 ASP.NET 应用程序生命周期的各个阶段

              发出一个对应用程序的请求

•       ASP.NET应用程序的生命周期以浏览器向Web服务器发送请求为起点。 在 IIS 7.0 经典模式下以及在 IIS 6.0 中，ASP.NET 请求管道与 Web 服务器管道分离。模块仅应用于路由到 ASP.NET ISAPI 扩展的请求。如果请求的资源类型的文件扩展名未显式映射到 ASP.NET，则不会为该请求调用 ASP.NET 功能，因为 ASP.NET 运行库没有处理该请求。

        而在 IIS 7.0 集成模式下，由一个统一的管道处理所有请求。当集成管道收到请求时，该请求将经历所有请求共有的一些阶段。这些阶段由 RequestNotification 枚举表示。所有请求都可以配置为使用 ASP.NET 功能，因为该功能封装在可以访问请求管道的托管代码模块中。例如，即使 .htm 文件扩展名未显式映射到 ASP.NET，对 HTML 页的请求仍会调用 ASP.NET 模块。这使我们能对所有资源使用 ASP.NET 身份验证和授权。

        统一管道接收对应用程序的第一个请求
•       

        当统一管道接收对应用程序中的任何资源的第一个请求时，将为 ApplicationManager 类创建一个实例，该实例就是处理请求的应用程序域。应用程序域提供了应用程序之间全局变量的分离，并且使每个应用程序能够单独卸载。在应用程序域中，将为 HostingEnvironment 类创建一个实例，该实例提供对有关应用程序的信息（如存储该应用程序的文件夹的名称）的访问。

        在第一个请求期间，如果需要，将对应用程序中的顶级项进行编译，其中包括 App_Code 文件夹中的应用程序代码（可在 App_Code 文件夹中包含自定义模块和处理程序）。

  
        为每个请求创建响应对象
•       

        在创建了应用程序域并对 HostingEnvironment 对象进行了实例化之后，将创建并初始化应用程序对象，如 HttpContext、HttpRequest 和 HttpResponse。HttpContext 类包含特定于当前应用程序请求的对象，如 HttpRequest 和 HttpResponse 对象。HttpRequest 对象包含有关当前请求的信息，包括 Cookie 和浏览器信息。HttpResponse 对象包含发送到客户端的响应，其中包括所有呈现的输出和 Cookie。

  
        将HttpApplication对象分配给请求
•       初始化所有应用程序对象之后，将通过创建 HttpApplication 类的实例来启动应用程序。如果应用程序有 Global.asax 文件，则 ASP.NET 会创建从 HttpApplication 类派生的 Global.aspx 类的实例。然后使用该派生类来表示应用程序。 

              第一次在应用程序中请求 ASP.NET 页或进程时，将创建 HttpApplication 类的一个新实例。不过，为了尽可能提高性能，可对多个请求重复使用 HttpApplication 实例。

   
      由HttpApplication管线处理请求

•       在处理请求时，HttpApplication 类会执行下列任务。

  1. 对请求进行验证，将检查浏览器发送的信息，并确定其是否包含潜在恶意标记。

  2. 如果已在 Web.config 文件的 UrlMappingsSection 节中配置了任何 URL，则执行 URL 映射。

  3. 引发 BeginRequest 事件。

  4. 引发 AuthenticateRequest 事件。

  5. 引发 PostAuthenticateRequest 事件。

  6. 引发 AuthorizeRequest 事件。

  7. 引发 PostAuthorizeRequest 事件。

  8. 引发 ResolveRequestCache 事件。

  9. 引发 PostResolveRequestCache 事件。

  10. 引发 MapRequestHandler 事件。将根据所请求资源的文件扩展名，选择相应的处理程序。处理程序可以是本机代码模块，如 IIS 7.0 StaticFileModule，也可以是托管代码模块，如 PageHandlerFactory 类（它处理 .aspx 文件）。

  11. 引发 PostMapRequestHandler 事件。

  12. 引发 AcquireRequestState 事件。

  13. 引发 PostAcquireRequestState 事件。

  14. 引发 PreRequestHandlerExecute 事件。

  15. 为该请求调用合适的 IHttpHandler 类的 ProcessRequest 方法（或异步版 IHttpAsyncHandler.BeginProcessRequest）。例如，如果该请求针对某页，则当前的页实例将处理该请求。

  16. 引发 PostRequestHandlerExecute 事件。

  17. 引发 ReleaseRequestState 事件。

  18. 引发 PostReleaseRequestState 事件。

  19. 如果定义了 Filter 属性，则执行响应筛选。

  20. 引发 UpdateRequestCache 事件。

  21. 引发 PostUpdateRequestCache 事件。

  22. 引发 LogRequest 事件。

  23. 引发 PostLogRequest 事件。

  24. 引发 EndRequest 事件。

  25. 引发 PreSendRequestHeaders 事件。

  26. 引发 PreSendRequestContent 事件。

1.数据库优化的时期：数据库的优化从设计，数据库的安装已经开始。

2.数据库性能的主要指标是响应时间。影响数据库增长率的表的种类：

A 静态参数表（应用相关表）：相对稳定

B动态数据表（事务相关表）：缓慢增长

C数据表（事务表）：增长的主要因素

D临时/接口表

3.数据库优化的主要方法：

A网络

B硬件优化  主要在应用程序调整的初期。

C操作系统的优化

.Unix系统

调整参数：共享内存和信号灯

监测工具：

工具    主要关心的参数

 iostat      bps和tps

vmstat     page fault,page pin,page pount

.WindowNT

         使不必要的服务失效

         取消屏幕保护

        只将机器用做数据库服务器

        如果是WINDOWSNT系统

        控制面扳中Network tool –Properties下面四个选项中选择Maximize Throughput for Network Application

        控制面扳中System tool—Performance中boost选择None，减少文件系统缓冲

        利用性能监视器监视数据库服务器，分析性能瓶颈

        利用微软资源工具箱(resources pake)中的工具（Process Viewer、Process Explode、Quick Slice、Process Stat）监视数据库服务器，决定操作系统是否优化

 D数据库系统优化

原理：合理的分配内存大小；合理的设置表空间体系和内部空间参数。

内存结构的优化是通过int.ora文件的环境参数来配置。

主要参数：db_block_size可增大，Shared_pool_size性能指标free memory,log_buffer

监测工具：a.toad或tora(linux) b.Utlbstat和utlestat这两个文件在oracle_home/rdbms/admin下，在运行脚本前注意更改tiemed_statistic为true，运行后查看report文件。

经验：表空间设计的时候应遵循oracle的最优化体系结构建议；db_block_buffers和library_cache都要保证合理的命中率；为了使全表扫描的效率最高，每个extent(数据区)都应该db_block_size*db_fiel_multiblock_read_count的倍数；如果是非常大的表，做sql*loader或者export操作时要使用direct选项，创建非常大的表和索引时要使用nologing选项。SELECT Segment_Name,BYTES/1024/1024,BLOCKS,EXTENTS FROM USER_SEGMENTS where Segment_Name = '&table_name';可以查看表的大小，占用多少个数据块，在segment上的extent数目；select Segment_Name,extent_id,bytes/64,blocks from user_extents where Segment_Name = '&table_name'可以查看每个extents上有多少数据块,每个extent需要做多少次多块读取。

E应用程序优化

批处理应用的优化：使用存储过程，经常使用的小表缓存（可创建表的时候缓存或在select中使用cache hint)，对大表整理（比如排序）。

单条Sql语句的优化：查找最影响性能的sql语句的方法

select Executions,
       Disk_Reads,
       Buffer_Gets,
       Round((Buffer_Gets - Disk_Reads) / Buffer_Gets, 2) Hit_Radio,
       Round(Disk_Reads / Executions, 2) Reads_Per_Run,
       Sql_Text
 from V$sqlarea
 where Executions > 0
       and Buffer_Gets > 0
       and (Buffer_Gets - Disk_Reads) / Buffer_Gets < 0.8
 order by 4 desc；

对大表创建索引：使用选择性高的索引，同时要控制索引的大小。

Code
<script type="text/javascript">
        function ChangeCheckBoxState(id, checkState) {
            var cb = document.getElementById(id);
            if (cb != null)
                cb.checked = checkState;
        }
        function ChangeAllCheckBoxState(checkState) {
            if (CheckBoxIDs != null) {
                for (var i = 0; i < CheckBoxIDs.length; i++)
                    ChangeCheckBoxState(CheckBoxIDs[i], checkState);
            }
        }
        function ChangeHeaderAsNeeded() {
            if (CheckBoxIDs != null) {
                for (var i = 1; i < CheckBoxIDs.length; i++) {
                    var cb = document.getElementById(CheckBoxIDs[i]);
                    if (!cb.checked) {
                        ChangeCheckBoxState(CheckBoxIDs[0], false);
                        return;
                    }
                }
                ChangeCheckBoxState(CheckBoxIDs[0], true);
            }
        }
    </script>


<asp:TemplateField>
                    <HeaderTemplate>
                        <asp:CheckBox runat="server" ID="HeaderLevelCheckbox" />
                    </HeaderTemplate>
                    <ItemTemplate>
                        <asp:CheckBox ID="ProductSelector" runat="server" />
                    </ItemTemplate>
                </asp:TemplateField>


protected void Products_DataBound(object sender, EventArgs e)
    {
        GridViewRow row = Products.HeaderRow;
        CheckBox cbHeader = (CheckBox)row.FindControl("HeaderLevelCheckbox");
        cbHeader.Attributes["onclick"] = "ChangeAllCheckBoxState(this.checked);";
        List<String> ArrayValues = new List<string>();
        ArrayValues.Add(String.Concat("'", cbHeader.ClientID, "'"));
        foreach (GridViewRow grv in Products.Rows)
        {
            CheckBox cb = (CheckBox)grv.FindControl("ProductSelector");
            cb.Attributes["onclick"] = "ChangeHeaderAsNeeded();";
            ArrayValues.Add(String.Concat("'", cb.ClientID, "'"));
        }
        CheckBoxIDsArray.Text = @"<script type=""text/javascript"">" + String.Concat("var CheckBoxIDs =  new Array(", String.Join(",", ArrayValues.ToArray()), ");") + "</script>";
    }

在查看效果的时候发现了一个非常奇怪的现象：点击ItemTemplate里的一个checkbox时全部的checkbox会同时选中，这明显与实际期望产生了偏差，于是决定通过调试看看为啥出现了这个偏差，查了一下也没有显示处理这块的代码。郁闷了一会后，想到既然全部选中应该是调用了ChangeAllCheckBoxState()这个函数，但何时调用的呢，在脚本处放断点，结果显示运行也正常啊，貌似也没什么问题。于是又很失望，就在要放弃的时候突然发现ChangeAllCheckBoxState(CheckBoxIDs[0], false);这句代码，再一看ChangeAllCheckBoxState()没有两个参数的方法，赶紧把它改回来，再看效果时已经好用了。只是纳闷，调试脚本的时候明明没有合适的方法为什么不报错呢？

    个人总结：有时候我们不可过分相信脚本调试器，在遇到异常的时候还是应该仔细分析可能出错的原因。