尽管在.NET framework下我们并不需要担心内存管理和垃圾回收(Garbage Collection)，但是我们还是应该了解它们，以优化我们的应用程序。
同时，还需要具备一些基础的内存管理工作机制的知识，这样能够有助于解释我们日常程序编写中的变量的行为。
在本文中我们将深入理解垃圾回收器，还有如何利用静态类成员来使我们的应用程序更高效。
* 更小的步伐 == 更高效的分配@H_301_11@
为了更好地理解为什么更小的足迹会更高效，这需要我们对.NET的内存分配和垃圾回收专研得更深一些。* 图解:
让我们来仔细看看GC。如果我们需要负责"清除垃圾"，那么我们需要拟定一个高效的方案。很显然，我们需要决定哪些东西是垃圾而哪些不是。
为了决定哪些是需要保留的，我们首先假设所有的东西都不是垃圾(墙角里堆着的旧报纸，阁楼里贮藏的废物，壁橱里的所有东西，等等)。
假设在我们的生活当中有两位朋友：Joseph Ivan Thomas(JIT)和Cindy Lorraine Richmond(CLR)。
Joe和Cindy知道它们在使用什么，而且给了我们一张列表说明了我们需要需要些什么。
我们将初始列表称之为"根"列表,因为我们将它用作起始点。我们需要保存一张主列表来记录出我们家中的必备物品。
任何能够使必备物品正常工作或使用的东西也将被添加到列表中来
(如果我们要看电视，那么就不能扔掉遥控器，所以遥控器将被添加到列表。如果我们要使用电脑，那么键盘和显示器就得添加到列表)。
这就是GC如何保存我们的物品的，它从即时编译器(JIT)和通用语言运行时(CLR)中获得"根"对象引用的列表，
然后递归地搜索出其他对象引用来建立一张我们需要保存的物品的图表。
根包括：@H_301_11@
* 全局/静态指针。 为了使我们的对象不被垃圾回收掉的一种方式是将它们的引用保存在静态变量中。
* 栈上的指针。 我们不想丢掉应用程序中需要执行的线程里的东西。
* cpu寄存器指针。托管堆中哪些被cpu寄存器直接指向的内存地址上的东西必须得保留。
在以上图片中，托管堆中的对象1、3、5都被根所引用，其中1和5时直接被引用，而3时在递归查找时被发现的。
像我们之前的假设一样，对象1是我们的电视机，对象3是我们的遥控器。在所有对象被递归查找出来之后我们将进入下一步--压缩。
* 压缩@H_301_11@
我们现在已经绘制出哪些是我们需要保留的对象，那么我们就能够通过移动"保留对象"来对托管堆进行整理。
幸运的是，在我们的房间里没有必要为了放入别的东西而去清理空间。
因为对象2已经不再需要了，所以GC会将对象3移下来，同时修复它指向对象1的指针。
然后，GC将对象5也向下移,
现在所有的东西都被清理干净了，我们只需要写一张便签贴到压缩后的堆上，让Claire(指CLR)知道在哪儿放入新的对象就行了。
理解GC的本质会让我们明白对象的移动是非常费力的。
可以看出，假如我们能够减少需要移动的物品大小是非常有意义的，通过更少的拷贝动作能够使我们提升整个GC的处理性能。
* 托管堆之外是怎样的情景呢？@H_301_11@
作为负责垃圾回收的人员，有一个容易出现入的问题是在打扫房间时如何处理车里的东西，当我们打扫卫生时，我们需要将所有物品清理干净。
那家里的台灯和车里的电池怎么办？
在一些情况下，GC需要执行代码来清理非托管资源(如文件，数据库连接，网络连接等)，一种可能的方式是通过finalizer来进行处理。
class Sample
{
~Sample()
{
// FINALIZER: CLEAN UP HERE
}
}
在对象创建期间，所有带有finalizer的对象都将被添加到一个finalizer队列中。
对象1、4、5都有finalizer，且都已在finalizer队列当中。让我们来看看当对象2和4在应用程序中不再被引用，且系统正准备进行垃圾回收时会发生些什么。
对象2会像通常情况下那样被垃圾回收器回收，但是当我们处理对象4时，
GC发现它存在于finalizer队列中，那么GC就不会回收对象4的内存空间，而是将对象4的finalizer移到一个叫做"freachable@H_301_11@"的特殊队列中。
Finalizer收尾: 每个类都有一个特殊的方法finalizer，它不能被直接调用，而被JVM在适当的时候调用，
通常用来处理一些清理资源的工作，因此称为收尾机制。
有一个专门的线程来执行freachable队列中的项，对象4的finalizer一旦被该线程所处理，就将从freachable队列中被移除，然后对象4就等待被回收。
因此对象4将存活至下一轮的垃圾回收。
由于在类中添加一个finalizer会增加GC的工作量，这种工作是十分昂贵的，而且会影响垃圾回收的性能和我们的程序。
最好只在你确认需要finalizer时才使用它。
在清理非托管资源时有一种更好的方法：在显式地关闭连接时，使用 IDisposalbe@H_301_11@接口来代替finalizer进行清理工作会更好些。* IDisposable@H_301_11@
实现IDisposable接口的类需要执行Dispose()方法来做清理工作(这个方法是IDisposable接口中唯一的签名)。
因此假如我们使用如下的带有finalizer的ResourceUser类：
public class ResourceUser
{
~ResourceUser() // THIS IS A FINALIZER 即析构
{
// DO CLEANUP HERE
}
}我们可以使用IDisposable来以更好的方式实现相同的功能：
public class ResourceUser : IDisposable
{
IDisposable Members
}
IDisposable被集成在了using块当中。
在using()方法中声明的对象在using块的结尾处将调用Dispose()方法，using块之外该对象将不再被引用，
因为它已经被认为是需要进行垃圾回收的对象了。
public static void DoSomething()
{
ResourceUser rec = new ResourceUser();
using (rec)
{
// DO SOMETHING
} // DISPOSE CALLED HERE
// DON'T ACCESS rec HERE
}
我更喜欢将对象声明放到using块中，因为这样可视化很强，而且rec对象在using块的作用域之外将不再有效。
这种模式的写法更符合IDisposable接口的初衷，但这并不是必须的。
public static void DoSomething()
{
using (ResourceUser rec = new ResourceUser())
{
// DO SOMETHING
} // DISPOSE CALLED HERE
}在类中使用using()块来实现IDisposable接口,能够使我们在清理垃圾对象时不需要写额外的代码来强制GC回收我们的对象。
* 静态方法@H_301_11@
静态方法属于一种类型，而不是对象的实例，它允许创建能够被类所共享的方法，且能够达到"减肥"的效果，因为只有静态方法的指针(8 bytes)在内存当中移动。
静态方法实体仅在应用程序生命周期的早期被一次性加载，而不是在我们的类实例中生成。
当然，方法越大那么将其作为静态就越高效。假如我们的方法很小(小于8 bytes)，那么将其作为静态方法反而会影响性能，
因为这时指针比它指向的方法所占的空间还大些。接着来看看例子...
我们的类中有一个公共的方法SayHello()：class Dude
{
private string _Name = "Don";
public void SayHello()
{
Console.WriteLine(this._Name + " says Hello");
}
} 在每一个Dude类实例中SayHello()方法都会占用内存空间。
一种更高效的方式是采用静态方法，这样我们只需要在内存中放置唯一的SayHello()方法，而不论存在多少个Dude类实例。
因为静态成员不是实例成员，我们不能使用this指针来进行方法的引用。
class Dude
{
private string _Name = "Don";
public static void SayHello(string pName)
{
Console.WriteLine(pName + " says Hello");
}
}
请注意我们在传递变量时栈上发生了些什么(可以参看<第二部分>)。
例如,一个静态方法需要很多参数而且没有什么复杂的逻辑，那么在使用静态方法时我们可能会降低性能。
* 静态变量：注意了！@H_301_11@
对于静态变量，有两件事情我们需要注意。假如我们的类中有一个静态方法用于返回一个唯一值，而下面的实现会造成bug：
class Counter
{
private static int s_Number = 0;
public static int GetNextNumber()
{
int newNumber = s_Number;
// DO SOME STUFF
s_Number = newNumber + 1;
return newNumber;
}
}假如有两个线程同时调用GetNextNumber()方法，而且它们在s_Number的值增加前都为newNumber分配了相同的值，那么它们将返回同样的结果!
我们需要显示地为方法中的静态变量锁住读/写内存的操作，以保证同一时刻只有一个线程能够执行它们。
线程管理是一个非常大的主题，而且有很多途径可以解决线程同步的问题。
使用lock关键字能让代码块在同一时刻仅能够被一个线程访问。
一种好的习惯是，你应该尽量锁较短的代码，因为在程序执行lock代码块时所有线程都要进入等待队列，这是非常低效的。
class Counter
{
private static int s_Number = 0;
public static int GetNextNumber()
{
lock (typeof(Counter))
{
int newNumber = s_Number;
// DO SOME STUFF
newNumber += 1;
s_Number = newNumber;
return newNumber;
}
}
}
* 静态变量：再次注意了！@H_301_11@
静态变量引用需要注意的另一件事情是：记住，被"root"引用的事物是不会被GC清理掉的。我遇到过的一个最烦人的例子：
class Olympics
{
public static Collection<Runner> TryoutRunners;
}
class Runner
{
private string _fileName;
private FileStream _fStream;
public void GetStats()
{
FileInfo fInfo = new FileInfo(_fileName);
_fStream = _fileName.OpenRead();
}
}
由于Runner集合在Olympics类中是静态的，不仅集合中的对象不会被GC释放(它们都直接被根所引用)，
而且你可能注意到了，每次执行GetStats()方法时都会为那个文件开放一个文件流，
因为它没有被关闭所以也不会被GC释放，这个代码将会给系统造成很大的灾难。
假如我们有100000个运动员来参加奥林匹克，那么会由于太多不可回收的对象而难以释放内存。天啦，多差劲的性能呀！
* Singleton@H_301_11@
有一种方法可以保证一个类的实例在内存中始终保持唯一，我们可以采用Gof中的Singleton模式。
(Gof:Gang of Four，一部非常具有代表性的设计模式书籍的作者别称，归纳了23种常用的设计模式)
public class Earth
{
private static Earth _instance = new Earth();
private Earth() { }
public static Earth GetInstance() { return _instance; }
}
我们的Earth类有一个私有构造器，所以Earth类能够执行它的构造器来创建一个Earth实例。
我们有一个Earth类的静态实例，还有一个静态方法来获得这个实例。
这种特殊的实现是线程安全的，因为CLR保证了静态变量的创建是线程安全的。
这是我认为在C#中实现singleton模式最为明智的方式。
* .NET Framework 2.0中的静态类@H_301_11@
在.NET 2.0 Framework中我们有一种静态类，此类中的所有成员都是静态的。
这中特性对于工具类是非常有用的，而且能够节省内存空间，因为该类只存在于内存中的某个地方，不能在任何情况下被实例化。
* 总结一下...@H_301_11@
总的来说,我们能够提升GC表现的方式有：
1. 清理工作。
不要让资源一直打开！尽可能地保证关闭所有打开的连接，清除所有非托管的资源。
当使用非托管对象时，初始化工作尽量完些，清理工作要尽量及时点。
2. 不要过度地引用。
需要时才使用引用对象，记住，如果你的对象是活动着的，所有被它引用的对象都不会被垃圾回收。
当我们想清理一些类所引用的事物，可以通过将这些引用设置为null来移除它们。
我喜欢采用的一种方式是将未使用的引用指向一个轻量级的NullObject来避免产生null引用的异常。
在GC进行垃圾回收时，更少的引用将减少映射处理的压力。
3. 少使用finalizer。
Finalizer在垃圾回收时是非常昂贵的资源，我们应该只在必要时使用。
如果我们使用IDisposable来代替finalizer会更高效些，因为我们的对象能够直接被GC回收而不是在第二次回收时进行。
4. 尽量保持对象和它们的子对象在一块儿。
GC在复制大块内存数据来放到一起时是很容易的，而复制堆中的碎片是很费劲的，
所以当我们声明一个包含许多其他对象的对象时，我们应该在初始化时尽量让他们在一块儿。
5. 最后，使用静态方法来保持对象的轻便也是可行的。 下一次，我们将更加深入GC的处理过程，看看在你的程序执行时GC是如何发现问题并清除它们的。 To be long long continued... 原文链接：https://www.f2er.com/vb/258789.html