继续：.NET中栈和堆的比较之三-四

今天将这系列的文章转载完，希望对感兴趣的朋友有所帮助！

.NET中栈和堆的比较三

原文出处
http://www.c-sharpcorner.com/UploadFile/rmcochran/chsarp_memory401152006094206AM/chsarp_memory4.aspx

尽管在.NET framework下我们并不需要担心内存管理和垃圾回收(Garbage Collection)，但是我们还是应该了解它们，以优化我们的应用程序。同时，还需要具备一些基础的内存管理工作机制的知识，这样能够有助于解释我们日常程序编写中的变量的行为。在本文中我们将涉及到堆中引用变量引起的问题，以及如何使用ICloneable接口来解决该问题。

需要回顾堆栈基础，值类型和引用类型，请转到第一部分和第二部分

* 副本并不是真的副本

为了清楚的阐明问题，让我们来比较一下当堆中存在值类型和引用类型时都发生了些什么。首先来看看值类型，如下面的类和结构。这里有一个类Dude，它的成员中有一个string型的Name字段及两个Shoe类型的字段--RightShoe、LeftShoe，还有一个CopyDude()方法可以很容易地生成新的Dude实例。

public struct Shoe{

public string Color;

}

public class Dude

{

public string Name;

public Shoe RightShoe;

public Shoe LeftShoe;

public Dude CopyDude()

{

Dude newPerson = new Dude();

newPerson.Name = Name;

newPerson.LeftShoe = LeftShoe;

newPerson.RightShoe = RightShoe;

return newPerson;

}

public override string ToString()

{

return (Name + " : Dude!, I have a " + RightShoe.Color +

" shoe on my right foot, and a " +

LeftShoe.Color + " on my left foot.");

}

}

Dude是引用类型，而且由于结构Shoe的两个字段是Dude类的成员，所以它们都被放在了堆上。

当我们执行以下的方法时：

public static void Main()

{

Class1 pgm = new Class1();

Dude Bill = new Dude();

Bill.Name = "Bill";

Bill.LeftShoe = new Shoe();

Bill.RightShoe = new Shoe();

Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue";

Dude Ted = Bill.CopyDude();

Ted.Name = "Ted";

Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red";

Console.WriteLine(Bill.ToString());

Console.WriteLine(Ted.ToString());

}

我们得到了预期的结果：

Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot.
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot.

如果我们将结构Shoe换成引用类型会发生什么？问题就在于此。
假如我们将Shoe改为引用类型：

public class Shoe{

public string Color;

}

然后在与前面相同的Main()方法中运行，再来看看我们的结果：

Bill : Dude!, I have a Red shoe on my right foot, and a Red on my left foot
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot

可以看到红鞋子被穿到别人(Bill)脚上了，很明显出错了。你想知道这是为什么吗？我们再来看看堆就明白了。

由于我们现在使用的Shoe是引用类型而非值类型，当引用类型的内容被拷贝时实际上只拷贝了该类型的指针(并没有拷贝实际的对象)，我们需要作一些额外的工作来使我们的引用类型能够像值类型一样使用。

幸运的是.NET Framework中已经有了一个IClonealbe接口(System.ICloneable)来帮助我们解决问题。使用这个接口可以规定所有的Dude类必须遵守和定义引用类型应如何被复制，以避免出现"共享鞋子"的问题。所有需要被克隆的类都需要使用ICloneable接口，包括Shoe类。

System.IClonealbe只有一个方法定义：Clone()

public object Clone()

{

}

我们应该在Shoe类中这样实现：

public class Shoe : ICloneable

{

public string Color;

#region ICloneable Members

public object Clone()

{

Shoe newShoe = new Shoe();

newShoe.Color = Color.Clone() as string;

return newShoe;

}

#endregion

}

在方法Clone()中，我们创建了一个新的Shoe对象，克隆了所有引用类型，并拷贝了所有值类型，然后返回了这个新对象。你可能注意到了string类已经实现了ICloneable接口，所以我们可以直接调用Color.Clone()方法。因为Clone()方法返回的是对象的引用,所以我们需要在设置鞋的颜色前重构这个引用。

接着，在我们的CopyDude()方法中我们需要克隆鞋子而非拷贝它们：

public Dude CopyDude()

{

Dude newPerson = new Dude();

newPerson.Name = Name;

newPerson.LeftShoe = LeftShoe.Clone() as Shoe;

newPerson.RightShoe = RightShoe.Clone() as Shoe;

return newPerson;

}

现在，当我们执行Main()函数时：

public static void Main()

{

Dude Bill = new Dude();

Bill.Name = "Bill";

Bill.LeftShoe = new Shoe();

Bill.RightShoe = new Shoe();

Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue";

Dude Ted = Bill.CopyDude();

Ted.Name = "Ted";

Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red";

Console.WriteLine(Bill.ToString());

Console.WriteLine(Ted.ToString());

}

我们得到的是：

Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot

这就是我们想要的。

在通常情况下，我们应该"克隆"引用类型，"拷贝"值类型。(这样，在你调试以上介绍的情况中的问题时，会减少你买来控制头痛的阿司匹林的药量)
在头痛减少的激烈下，我们可以更进一步地使用Dude类来实现IClonealbe，而不是使用CopyDude()方法。

public class Dude: ICloneable

{

public string Name;

public Shoe RightShoe;

public Shoe LeftShoe;

public override string ToString()

{

return (Name + " : Dude!, I have a " + RightShoe.Color +

" shoe on my right foot, and a " +

LeftShoe.Color + " on my left foot.");

}

#region ICloneable Members

public object Clone()

{

Dude newPerson = new Dude();

newPerson.Name = Name.Clone() as string;

newPerson.LeftShoe = LeftShoe.Clone() as Shoe;

newPerson.RightShoe = RightShoe.Clone() as Shoe;

return newPerson;

}

#endregion

}

然后我们将Main()方法中的Dude.CopyDude()方法改为Dude.Clone()：

public static void Main()

{

Dude Bill = new Dude();

Bill.Name = "Bill";

Bill.LeftShoe = new Shoe();

Bill.RightShoe = new Shoe();

Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue";

Dude Ted = Bill.Clone() as Dude;

Ted.Name = "Ted";

Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red";

Console.WriteLine(Bill.ToString());

Console.WriteLine(Ted.ToString());
}

最后的结果是：

Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot.
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot.

非常好！

比较有意思的是请注意为System.String类分配的操作符("="号),它实际上是将string型对象进行克隆，所以你不必担心会发生引用拷贝。尽管如此你还是得注意一下内存的膨胀。
如果你重新看一下前面的那些图，会发现string型应该是引用类型，所以它应该是一个指针(这个指针指向堆中的另一个对象)，但是为了方便起见，我在图中将string型表示为值类型(实际上应该是一个指针)，因为通过"="号重新被赋值的string型对象实际上是被自动克隆过后的。

总结一下：

通常，如果我们打算将我们的对象用于拷贝，那么我们的类应该实现IClonealbe借口，这样能够使引用类型仿效值类型的行为。从中可以看到，搞清楚我们所使用的变量的类型是非常重要的，因为在值类型和引用类型的对象在内存中的分配是有区别的。

在下一部分内容中，会看到我们是怎样来减少代码在内存中的"脚印"的，将会谈到期待已久的垃圾回收器(Garbage Collection)。

To be continued...

.NET中栈和堆的比较-四

终于翻完了第四篇，本来每次都是周末发的，可惜上周末有些事儿没忙过来，所以今天中午给补上来。不知道这套文章还能不能继续了，因为作者也只写到了第四篇，连他都不知道第五篇什么时候出得来...
原文出处
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory_401282006141834PM/csharp_memory_4.aspx
可以参看该系列文章的前面部分内容：Part I，Part II，Part III
尽管在.NET framework下我们并不需要担心内存管理和垃圾回收(Garbage Collection)，但是我们还是应该了解它们，以优化我们的应用程序。同时，还需要具备一些基础的内存管理工作机制的知识，这样能够有助于解释我们日常程序编写中的变量的行为。在本文中我们将深入理解垃圾回收器，还有如何利用静态类成员来使我们的应用程序更高效。

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

为了更好地理解为什么更小的足迹会更高效，这需要我们对.NET的内存分配和垃圾回收专研得更深一些。

* 图解:

让我们来仔细看看GC。如果我们需要负责"清除垃圾"，那么我们需要拟定一个高效的方案。很显然，我们需要决定哪些东西是垃圾而哪些不是。
为了决定哪些是需要保留的，我们首先假设所有的东西都不是垃圾(墙角里堆着的旧报纸，阁楼里贮藏的废物，壁橱里的所有东西，等等)。假设在我们的生活当中有两位朋友：Joseph Ivan Thomas(JIT)和Cindy Lorraine Richmond(CLR)。Joe和Cindy知道它们在使用什么，而且给了我们一张列表说明了我们需要需要些什么。我们将初始列表称之为"根"列表,因为我们将它用作起始点。我们需要保存一张主列表来记录出我们家中的必备物品。任何能够使必备物品正常工作或使用的东西也将被添加到列表中来(如果我们要看电视，那么就不能扔掉遥控器，所以遥控器将被添加到列表。如果我们要使用电脑，那么键盘和显示器就得添加到列表)。

这就是GC如何保存我们的物品的，它从即时编译器(JIT)和通用语言运行时(CLR)中获得"根"对象引用的列表，然后递归地搜索出其他对象引用来建立一张我们需要保存的物品的图表。

根包括：

* 全局/静态指针。为了使我们的对象不被垃圾回收掉的一种方式是将它们的引用保存在静态变量中。
* 栈上的指针。我们不想丢掉应用程序中需要执行的线程里的东西。
* CPU寄存器指针。托管堆中哪些被CPU寄存器直接指向的内存地址上的东西必须得保留。

在以上图片中，托管堆中的对象1、3、5都被根所引用，其中1和5时直接被引用，而3时在递归查找时被发现的。像我们之前的假设一样，对象1是我们的电视机，对象3是我们的遥控器。在所有对象被递归查找出来之后我们将进入下一步--压缩。

* 压缩

我们现在已经绘制出哪些是我们需要保留的对象，那么我们就能够通过移动"保留对象"来对托管堆进行整理。

幸运的是，在我们的房间里没有必要为了放入别的东西而去清理空间。因为对象2已经不再需要了，所以GC会将对象3移下来，同时修复它指向对象1的指针。

然后，GC将对象5也向下移,

现在所有的东西都被清理干净了，我们只需要写一张便签贴到压缩后的堆上，让Claire(指CLR)知道在哪儿放入新的对象就行了。

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

* 托管堆之外是怎样的情景呢？

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

在一些情况下，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"的特殊队列中。

有一个专门的线程来执行freachable队列中的项，对象4的finalizer一旦被该线程所处理，就将从freachable队列中被移除，然后对象4就等待被回收。

因此对象4将存活至下一轮的垃圾回收。

由于在类中添加一个finalizer会增加GC的工作量，这种工作是十分昂贵的，而且会影响垃圾回收的性能和我们的程序。最好只在你确认需要finalizer时才使用它。

在清理非托管资源时有一种更好的方法：在显式地关闭连接时，使用IDisposalbe接口来代替finalizer进行清理工作会更好些。

* IDisposable

实现IDisposable接口的类需要执行Dispose()方法来做清理工作(这个方法是IDisposable接口中唯一的签名)。因此假如我们使用如下的带有finalizer的ResourceUser类：

public class ResourceUser

{

~ResourceUser() // THIS IS A FINALIZER

{

// DO CLEANUP HERE

}

}

我们可以使用IDisposable来以更好的方式实现相同的功能：

public class ResourceUser : IDisposable

{

IDisposable Members#region IDisposable Members

public void Dispose()

{

// CLEAN UP HERE!!!

}

#endregion

}

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回收我们的对象。

* 静态方法

静态方法属于一种类型，而不是对象的实例，它允许创建能够被类所共享的方法，且能够达到"减肥"的效果，因为只有静态方法的指针(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");

}

}

请注意我们在传递变量时栈上发生了些什么(可以参看<第二部分>)。我们需要通过例子的看看是否需要使用静态方法来提升性能。例如,一个静态方法需要很多参数而且没有什么复杂的逻辑，那么在使用静态方法时我们可能会降低性能。

* 静态变量：注意了！

对于静态变量，有两件事情我们需要注意。假如我们的类中有一个静态方法用于返回一个唯一值，而下面的实现会造成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;

}

}

}

* 静态变量：再次注意了！

静态变量引用需要注意的另一件事情是：记住，被"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

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

在.NET 2.0 Framework中我们有一种静态类，此类中的所有成员都是静态的。这中特性对于工具类是非常有用的，而且能够节省内存空间，因为该类只存在于内存中的某个地方，不能在任何情况下被实例化。

* 总结一下...

总的来说,我们能够提升GC表现的方式有：

1. 清理工作。不要让资源一直打开！尽可能地保证关闭所有打开的连接，清除所有非托管的资源。当使用非托管对象时，初始化工作尽量完些，清理工作要尽量及时点。

2. 不要过度地引用。需要时才使用引用对象，记住，如果你的对象是活动着的，所有被它引用的对象都不会被垃圾回收。当我们想清理一些类所引用的事物，可以通过将这些引用设置为null来移除它们。我喜欢采用的一种方式是将未使用的引用指向一个轻量级的NullObject来避免产生null引用的异常。在GC进行垃圾回收时，更少的引用将减少映射处理的压力。

3. 少使用finalizer。Finalizer在垃圾回收时是非常昂贵的资源，我们应该只在必要时使用。如果我们使用IDisposable来代替finalizer会更高效些，因为我们的对象能够直接被GC回收而不是在第二次回收时进行。

4. 尽量保持对象和它们的子对象在一块儿。GC在复制大块内存数据来放到一起时是很容易的，而复制堆中的碎片是很费劲的，所以当我们声明一个包含许多其他对象的对象时，我们应该在初始化时尽量让他们在一块儿。

5. 最后，使用静态方法来保持对象的轻便也是可行的。

下一次，我们将更加深入GC的处理过程，看看在你的程序执行时GC是如何发现问题并清除它们的。

To be long long continued...