Net堆与栈的区别（4）清理垃圾也是技术活

尽管在.NET framework下我们并不需要担心内存管理和垃圾回收(Garbage Collection)，但是我们还是应该了解它们，以优化我们的应用程序。

同时，还需要具备一些基础的内存管理工作机制的知识，这样能够有助于解释我们日常程序编写中的变量的行为。

在本文中我们将深入理解垃圾回收器，还有如何利用静态类成员来使我们的应用程序更高效。

* 更小的步伐 == 更高效的分配

为了决定哪些是需要保留的，我们首先假设所有的东西都不是垃圾(墙角里堆着的旧报纸，阁楼里贮藏的废物，壁橱里的所有东西，等等)。

假设在我们的生活当中有两位朋友：Joseph Ivan Thomas(JIT)和Cindy Lorraine Richmond(CLR)。

Joe和Cindy知道它们在使用什么，而且给了我们一张列表说明了我们需要需要些什么。

我们将初始列表称之为"根"列表,因为我们将它用作起始点。我们需要保存一张主列表来记录出我们家中的必备物品。

任何能够使必备物品正常工作或使用的东西也将被添加到列表中来

(如果我们要看电视，那么就不能扔掉遥控器，所以遥控器将被添加到列表。如果我们要使用电脑，那么键盘和显示器就得添加到列表)。

这就是GC如何保存我们的物品的，它从即时编译器(JIT)和通用语言运行时(CLR)中获得"根"对象引用的列表，

然后递归地搜索出其他对象引用来建立一张我们需要保存的物品的图表。

像我们之前的假设一样，对象1是我们的电视机，对象3是我们的遥控器。在所有对象被递归查找出来之后我们将进入下一步--压缩。

幸运的是，在我们的房间里没有必要为了放入别的东西而去清理空间。

因为对象2已经不再需要了，所以GC会将对象3移下来，同时修复它指向对象1的指针。

理解GC的本质会让我们明白对象的移动是非常费力的。

可以看出，假如我们能够减少需要移动的物品大小是非常有意义的，通过更少的拷贝动作能够使我们提升整个GC的处理性能。

作为负责垃圾回收的人员，有一个容易出现入的问题是在打扫房间时如何处理车里的东西，当我们打扫卫生时，我们需要将所有物品清理干净。

那家里的台灯和车里的电池怎么办？

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"的特殊队列中。

Finalizer收尾: 每个类都有一个特殊的方法finalizer，它不能被直接调用，而被JVM在适当的时候调用，

通常用来处理一些清理资源的工作，因此称为收尾机制。

由于在类中添加一个finalizer会增加GC的工作量，这种工作是十分昂贵的，而且会影响垃圾回收的性能和我们的程序。

最好只在你确认需要finalizer时才使用它。

实现IDisposable接口的类需要执行Dispose()方法来做清理工作(这个方法是IDisposable接口中唯一的签名)。

因此假如我们使用如下的带有finalizer的ResourceUser类：

public class ResourceUser 
{
          ~ResourceUser() // THIS IS A FINALIZER 即析构
          {
                    // DO CLEANUP HERE
          }
}

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
}

静态方法属于一种类型，而不是对象的实例，它允许创建能够被类所共享的方法，且能够达到"减肥"的效果，因为只有静态方法的指针(8 bytes)在内存当中移动。

静态方法实体仅在应用程序生命周期的早期被一次性加载，而不是在我们的类实例中生成。

当然，方法越大那么将其作为静态就越高效。假如我们的方法很小(小于8 bytes)，那么将其作为静态方法反而会影响性能，

因为这时指针比它指向的方法所占的空间还大些。接着来看看例子...

class Dude
{
          private string _Name = "Don";
          public void SayHello()
          {
                    Console.WriteLine(this._Name + " says Hello");
          }
} 

一种更高效的方式是采用静态方法，这样我们只需要在内存中放置唯一的SayHello()方法，而不论存在多少个Dude类实例。

因为静态成员不是实例成员，我们不能使用this指针来进行方法的引用。

class Dude
{
          private string _Name = "Don";
          public static void SayHello(string pName)
          {
                    Console.WriteLine(pName + " says Hello");
          }
} 

请注意我们在传递变量时栈上发生了些什么(可以参看<第二部分>)。

我们需要通过例子的看看是否需要使用静态方法来提升性能。

例如,一个静态方法需要很多参数而且没有什么复杂的逻辑，那么在使用静态方法时我们可能会降低性能。

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;
          }
}

我们需要显示地为方法中的静态变量锁住读/写内存的操作，以保证同一时刻只有一个线程能够执行它们。

线程管理是一个非常大的主题，而且有很多途径可以解决线程同步的问题。

使用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;
                    }
          }
}

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个运动员来参加奥林匹克，那么会由于太多不可回收的对象而难以释放内存。天啦，多差劲的性能呀！

有一种方法可以保证一个类的实例在内存中始终保持唯一，我们可以采用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 2.0 Framework中我们有一种静态类，此类中的所有成员都是静态的。

这中特性对于工具类是非常有用的，而且能够节省内存空间，因为该类只存在于内存中的某个地方，不能在任何情况下被实例化。

1. 清理工作。

不要让资源一直打开！尽可能地保证关闭所有打开的连接，清除所有非托管的资源。

当使用非托管对象时，初始化工作尽量完些，清理工作要尽量及时点。

2. 不要过度地引用。

需要时才使用引用对象，记住，如果你的对象是活动着的，所有被它引用的对象都不会被垃圾回收。

当我们想清理一些类所引用的事物，可以通过将这些引用设置为null来移除它们。

我喜欢采用的一种方式是将未使用的引用指向一个轻量级的NullObject来避免产生null引用的异常。

在GC进行垃圾回收时，更少的引用将减少映射处理的压力。

3. 少使用finalizer。

Finalizer在垃圾回收时是非常昂贵的资源，我们应该只在必要时使用。

如果我们使用IDisposable来代替finalizer会更高效些，因为我们的对象能够直接被GC回收而不是在第二次回收时进行。

4. 尽量保持对象和它们的子对象在一块儿。

GC在复制大块内存数据来放到一起时是很容易的，而复制堆中的碎片是很费劲的，

所以当我们声明一个包含许多其他对象的对象时，我们应该在初始化时尽量让他们在一块儿。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!