原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx

儘管在.NET framework下我們並不需要擔心記憶體管理和垃圾回收(Garbage Collection)，但是我們還是應該瞭解它們，以優化我們的應用程式。同時，還需要具備一些基礎的記憶體管理工作機制的知識，這樣能夠有助於解釋我們日常程式編寫中的變數的行為。在本文中我將講解棧和堆的基本知識，變數型別以及為什麼一些變數能夠按照它們自己的方式工作。

在.NET framework環境下，當我們的程式碼執行時，記憶體中有兩個地方用來儲存這些程式碼

。假如你不曾瞭解，那就讓我來給你介紹棧(Stack)和堆(Heap)。棧和堆都用來幫助我們執行程式碼的，它們駐留在機器記憶體中，且包含所有程式碼執行所需要的資訊。

* 棧vs堆：有什麼不同？

棧負責儲存我們的程式碼執行（或呼叫）路徑,而堆則負責儲存物件（或者說資料，接下來將談到很多關於堆的問題）的路徑。

可以將棧想象成一堆從頂向下堆疊的盒子。當每呼叫一次方法時，我們將應用程式中所要發生的事情記錄在棧頂的一個盒子中,而我們每次只能夠使用棧頂的那個盒子。當我們棧頂的盒子被使用完之後，或者說方法執行完畢之後，我們將拋開這個盒子然後繼續使用棧頂上的新盒子。堆的工作原理比較相似，但大多數時候堆用作儲存資訊而非儲存執行路徑，因此堆能夠在任意時間被訪問。

與棧相比堆沒有任何訪問限制，堆就像床上的舊衣服，我們並沒有花時間去整理，那是因為可以隨時找到一件我們需要的衣服，而棧就像儲物櫃裡堆疊的鞋盒，我們只能從最頂層的盒子開始取，直到發現那隻合適的。

[heapvsstack1.gif]

以上圖片並不是記憶體中真實的表現形式，但能夠幫助我們區分棧和堆。

棧是自行維護的，也就是說記憶體自動維護棧，當棧頂的盒子不再被使用，它將被丟擲。相反的，堆需要考慮垃圾回收，垃圾回收用於保持堆的整潔性，沒有人願意看到周圍都是贓衣服，那簡直太臭了！

* 棧和堆裡有些什麼？

當我們的程式碼執行的時候，棧和堆中主要放置了四種類型的資料：值型別(Value Type)，引用型別(Reference Type)，指標(Pointer)，指令(Instruction)。

1.值型別：

在C#中，所有被宣告為以下型別的事物被稱為值型別：

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

2.引用型別：

所有的被宣告為以下型別的事物被稱為引用型別：

class 
interface 
delegate 
object 
string ，賦值的時候是複製一份，與引用型別不同

3.指標：

在記憶體管理方案中放置的第三種類型是型別引用，引用通常就是一個指標。我們不會顯示的使用指標，它們由公共語言執行時（CLR）來管理。指標（或引用）是不同於引用型別的，是因為當我們說某個事物是一個引用型別時就意味著我們是通過指標來訪問它的。指標是一塊記憶體空間，而它指向另一個記憶體空間。就像棧和堆一樣，指標也同樣要佔用記憶體空間，但它的值是一個記憶體地址或者為空。

[heapvsstack2.gif]

4.指令：

在後面的文章中你會看到指令是如何工作的...

* 如何決定放哪兒?

這裡有一條黃金規則:

1. 引用型別總是放在堆中。(夠簡單的吧?)

2. 值型別和指標總是放在它們被宣告的地方。(這條稍微複雜點，需要知道棧是如何工作的，然後才能斷定是在哪兒被宣告的。)

就像我們先前提到的，棧是負責儲存我們的程式碼執行(或呼叫)時的路徑。當我們的程式碼開始呼叫一個方法時,將放置一段編碼指令(在方法中)到棧上,緊接著放置方法的引數，然後程式碼執行到方法中的被“壓棧”至棧頂的變數位置。通過以下例子很容易理解...

下面是一個方法（Method）:

           public int AddFive(int pValue)
          {
                int result;
                result = pValue + 5;
                return result;
          }

現在就來看看在棧頂發生了些什麼，記住我們所觀察的棧頂下實際已經壓入了許多別的內容。

首先方法（只包含需要執行的邏輯位元組，即執行該方法的指令，而非方法體內的資料）入棧，緊接著是方法的引數入棧。（我們將在後面討論更多的引數傳遞）

[heapvsstack3.gif]

接著，控制（即執行方法的執行緒）被傳遞到堆疊中AddFive()的指令上，

[heapvsstack4.gif]

當方法執行時，我們需要在棧上為“result”變數分配一些記憶體，

[heapvsstack5.gif]

The method finishes execution and our result is returned.
方法執行完成，然後方法的結果被返回。

[heapvsstack6.gif]

通過將棧指標指向AddFive()方法曾使用的可用的記憶體地址，所有在棧上的該方法所使用記憶體都被清空，且程式將自動回到棧上最初的方法呼叫的位置(在本例中不會看到)。

[heapvsstack7.gif]

在這個例子中，我們的"result"變數是被放置在棧上的，事實上，當值型別資料在方法體中被宣告時，它們都是被放置在棧上的。

值型別資料有時也被放置在堆上。記住這條規則--值型別總是放在它們被宣告的地方。好的，如果一個值型別資料在方法體外被宣告，且存在於一個引用型別中，那麼它將被堆中的引用型別所取代。

來看另一個例子：

假如我們有這樣一個MyInt類（它是引用型別因為它是一個類型別）：

          public class MyInt
          {          
             public int MyValue;
          }

然後執行下面的方法:

          public MyInt AddFive(int pValue)
          {
                MyInt result = new MyInt();
                result.MyValue = pValue + 5;
                return result;
          }

就像前面提到的，方法及方法的引數被放置到棧上，接下來，控制被傳遞到堆疊中AddFive()的指令上。

[heapvsstack8.gif]

接著會出現一些有趣的現象...

因為"MyInt"是一個引用型別,它將被放置在堆上,同時在棧上生成一個指向這個堆的指標引用。

[heapvsstack9.gif]

在AddFive()方法被執行之後，我們將清空...

[heapvsstack10.gif]

我們將剩下孤獨的MyInt物件在堆中（棧中將不會存在任何指向MyInt物件的指標!）

[heapvsstack11.gif]

這就是垃圾回收器（後簡稱GC）起作用的地方。當我們的程式達到了一個特定的記憶體閥值(32bit 機給每個程式分配4G記憶體)，我們需要更多的堆空間的時候，GC開始起作用。GC將停止所有正在執行的執行緒，找出在堆中存在的所有不再被主程式訪問的物件，並刪除它們。然後GC會重新組織堆中所有剩下的物件來節省空間，並調整棧和堆中所有與這些物件相關的指標。你肯定會想到這個過程非常耗費效能，所以這時你就會知道為什麼我們需要如此重視棧和堆裡有些什麼，特別是在需要編寫高效能的程式碼時。

Ok... 這太棒了, 當它是如何影響我的？

Good question. 

當我們使用引用型別時，我們實際是在處理該型別的指標，而非該型別本身。當我們使用值型別時，我們是在使用值型別本身。聽起來很迷糊吧？

同樣，例子是最好的描述。

假如我們執行以下的方法：

          public int ReturnValue()
          {
                int x = new int();
                x = 3;
                int y = new int();
                y = x;      
                y = 4;          
                return x;
          }

我們將得到值3，很簡單，對吧？

假如我們首先使用MyInt類

     public class MyInt
          {
                public int MyValue;
          }

接著執行以下的方法：

          public int ReturnValue2()
          {
                MyInt x = new MyInt();
                x.MyValue = 3;
                MyInt y = new MyInt();
                y = x;                 
                y.MyValue = 4;              
                return x.MyValue;
          }

我們將得到什麼？...    4!

為什麼？...  x.MyValue怎麼會變成4了呢？...  看看我們所做的然後就知道是怎麼回事了：

在第一例子中，一切都像計劃的那樣進行著：

          public int ReturnValue()
          {
                int x = 3;
                int y = x;    
                y = 4;
                return x;
          }

[heapvsstack12.gif]

在第二個例子中，我們沒有得到"3"是因為變數"x"和"y"都同時指向了堆中相同的物件。
          public int ReturnValue2()
          {
                MyInt x;
                x.MyValue = 3;
                MyInt y;
                y = x;                
                y.MyValue = 4;
                return x.MyValue;
          }

[heapvsstack13.gif]

希望以上內容能夠使你對C#中的值型別和引用型別的基本區別有一個更好的認識，並且對指標及指標是何時被使用的有一定的基本瞭解。在系列的下一個部分，我們將深入記憶體管理並專門討論方法引數。

To be continued...

.NET中棧和堆的比較 #2

原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory2B01142006125918PM/csharp_memory2B.aspx


儘管在.NET framework下我們並不需要擔心記憶體管理和垃圾回收(Garbage Collection)，但是我們還是應該瞭解它們，以優化我們的應用程式。同時，還需要具備一些基礎的記憶體管理工作機制的知識，這樣能夠有助於解釋我們日常程式編寫中的變數的行為。在本文中我將講解我們必須要注意的方法傳參的行為。

在第一部分裡我介紹了棧和堆的基本功能，還介紹到了在程式執行時值型別和引用型別是如何分配的，而且還談到了指標。

* 引數，大問題

這裡有一個程式碼執行時的詳細介紹，我們將深入第一部分出現的方法呼叫過程...

當我們呼叫一個方法時，會發生以下的事情：

1.方法執行時，首先在棧上為物件例項中的方法分配空間，然後將方法拷貝到棧上（此時的棧被稱為幀），但是該空間中只存放了執行方法的指令，並沒有方法內的資料項。

3.方法引數的分配和拷貝是需要空間的，這一點是我們需要進一步注意。

示例程式碼如下:

          public int AddFive(int pValue)
          {
                int result;
                result = pValue + 5;
                return result;
          }

此時棧開起來是這樣的:

就像第一部分討論的那樣，放在棧上的引數是如何被處理的，需要看看它是值型別還是引用型別。值型別的值將被拷貝到棧上，而引用型別的引用（或者說指標）將被拷貝到棧上。

* 值型別傳遞

首先，當我們傳遞一個值型別引數時，棧上被分配好一個新的空間，然後該引數的值被拷貝到此空間中。

來看下面的方法：

     class Class1
     {

          public void Go()
          {

              int x = 5;
              
              AddFive(x);

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

          public int AddFive(int pValue)
          {

              pValue += 5;

              return pValue;
          }
     }

方法Go()被放置到棧上，然後執行，整型變數"x"的值"5"被放置到棧頂空間中。

然後AddFive()方法被放置到棧頂上，接著方法的形參值被拷貝到棧頂，且該形參的值就是"x"的拷貝。

當AddFive()方法執行完成之後，執行緒就通過預先放置的指令返回到Go()方法的地址，然後從棧頂依次將變數pValue和方法AddFive()移除掉:

所以我們的程式碼輸出的值是"5"，對吧？這裡的關鍵之處就在於任何傳入方法的值型別引數都是複製拷貝的，所以原始變數中的值是被保留下來而沒有被改變的。

必須注意的是，如果我們要將一個非常大的值型別資料(如資料量大的struct型別)入棧，它會佔用非常大的記憶體空間，而且會佔有過多的處理器週期來進行拷貝複製。棧並沒有無窮無盡的空間，它就像在水龍頭下盛水的杯子，隨時可能溢位。struct是一個能夠存放大量資料的值型別成員，我們必須小心地使用。

這裡有一個存放大資料型別的struct:

           public struct MyStruct

           {

               long a, b, c, d, e, f, g, h, i, j, k, l, m;

           }

來看看當我們執行了Go()和DoSometing()方法時會發生什麼：

          public void Go()

          {

             MyStruct x = new MyStruct();

             DoSomething(x);

          }

           public void DoSomething(MyStruct pValue)
           
           {
           
                    // DO SOMETHING HERE....

           }

這將會非常的低效。想象我們要是傳遞2000次MyStruct,你就會明白程式是怎麼癱瘓掉的了。

那麼我們應該如何解決這個問題？可以通過下列方式來傳遞原始值的引用：

          public void Go()

          {

             MyStruct x = new MyStruct();

             DoSomething(ref x);

          }

           public struct MyStruct

           {

               long a, b, c, d, e, f, g, h, i, j, k, l, m;

           }

           public void DoSomething(ref MyStruct pValue)

           {

                    // DO SOMETHING HERE....

           }

通過這種方式我們能夠提高記憶體中物件分配的效率。

唯一需要注意的是，在我們通過引用傳遞值型別時我們會修改該值型別的值，也就是說pValue值的改變會引起x值的改變。執行以下程式碼，我們的結果會變成"123456"，這是因為pValue實際指向的記憶體空間與ｘ變數宣告的記憶體空間是一致的。
          
          public void Go()

          {

             MyStruct x = new MyStruct();

             x.a = 5;

             DoSomething(ref x);

             Console.WriteLine(x.a.ToString());

          }

          public void DoSomething(ref MyStruct pValue)

          {

                   pValue.a = 12345;

          }

* 引用型別傳遞

傳遞引用型別引數的情況類似於先前例子中通過引用來傳遞值型別的情況。

如果我們使用引用型別：

           public class MyInt

           {

               public int MyValue;

           }

然後呼叫Go()方法，MyInt物件將放置在堆上：

          public void Go()

          {

             MyInt x = new MyInt();              

          }

如果我們執行下面的Go()方法：

          public void Go()

          {

             MyInt x = new MyInt();

             x.MyValue = 2;

             DoSomething(x);

             Console.WriteLine(x.MyValue.ToString());

          }

           public void DoSomething(MyInt pValue)

           {

               pValue.MyValue = 12345;

           }

將發生這樣的事情...

1.方法Go()入棧
2.Go()方法中的變數x入棧
3.方法DoSomething()入棧
4.引數pValue入棧
5.ｘ的值(MyInt物件的在棧中的指標地址)被拷貝到pValue中

因此，當我們通過MyInt型別的pValue來改變堆中MyInt物件的MyValue成員值後，接著又使用指向該物件的另一個引用ｘ來獲取了其MyValue成員值，得到的值就變成了"12345"。

而更有趣的是，當我們通過引用來傳遞一個引用型別時，會發生什麼？

讓我們來檢驗一下。假如我們有一個"Thing"類和兩個繼承於"Thing"的"Animal"和"Vegetable" 類：
           
           public class Thing

           {

           }

           public class Animal:Thing

           {

               public int Weight;

           }

           public class Vegetable:Thing

           {

               public int Length;

           }

然後執行下面的Go()方法：

          public void Go()

          {

             Thing x = new Animal();

             Switcharoo(ref x);

              Console.WriteLine(

                "x is Animal    :   "

                + (x is Animal).ToString());

              Console.WriteLine(

                  "x is Vegetable :   "

                  + (x is Vegetable).ToString());

          }

           public void Switcharoo(ref Thing pValue)

           {

               pValue = new Vegetable();

           }

變數ｘ被返回為Vegetable型別。

x is Animal    :   False
x is Vegetable :   True

讓我們來看看發生了什麼：

1.Go()方法入棧
2.x指標入棧
3.Animal物件例項化到堆中
4.Switcharoo()方法入棧
5.pValue入棧且指向ｘ

6.Vegetable物件例項化到堆中
7.x的值通過被指向Vegetable物件地址的pValue值所改變。

如果我們不使用Thing的引用，相反的，我們得到結果變數x將會是Animal型別的。

如果以上程式碼對你來說沒有什麼意義，那麼請繼續看看我的文章中關於引用變數的介紹，這樣能夠對引用型別的變數是如何工作的會有一個更好的理解。

我們看到了記憶體是怎樣處理引數傳遞的，在系列的下一部分中，我們將看看棧中的引用變數發生了些什麼，然後考慮當我們拷貝物件時是如何來解決某些問題的。

To be continued...

.NET中棧和堆的比較 #3

原文出處
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...

終於翻完了第四篇，本來每次都是週末發的，可惜上週末有些事兒沒忙過來，所以今天中午給補上來。不知道這套文章還能不能繼續了，因為作者也只寫到了第四篇，連他都不知道第五篇什麼時候出得來...

原文出處
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

在物件建立期間，所有帶有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

}

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是如何發現問題並清除它們的。

原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx

儘管在.NET framework下我們並不需要擔心記憶體管理和垃圾回收(Garbage Collection)，但是我們還是應該瞭解它們，以優化我們的應用程式。同時，還需要具備一些基礎的記憶體管理工作機制的知識，這樣能夠有助於解釋我們日常程式編寫中的變數的行為。在本文中我將講解棧和堆的基本知識，變數型別以及為什麼一些變數能夠按照它們自己的方式工作。

在.NET framework環境下，當我們的程式碼執行時，記憶體中有兩個地方用來儲存這些程式碼。假如你不曾瞭解，那就讓我來給你介紹棧(Stack)和堆(Heap)。棧和堆都用來幫助我們執行程式碼的，它們駐留在機器記憶體中，且包含所有程式碼執行所需要的資訊。

* 棧vs堆：有什麼不同？

棧負責儲存我們的程式碼執行（或呼叫）路徑,而堆則負責儲存物件（或者說資料，接下來將談到很多關於堆的問題）的路徑。

可以將棧想象成一堆從頂向下堆疊的盒子。當每呼叫一次方法時，我們將應用程式中所要發生的事情記錄在棧頂的一個盒子中,而我們每次只能夠使用棧頂的那個盒子。當我們棧頂的盒子被使用完之後，或者說方法執行完畢之後，我們將拋開這個盒子然後繼續使用棧頂上的新盒子。堆的工作原理比較相似，但大多數時候堆用作儲存資訊而非儲存執行路徑，因此堆能夠在任意時間被訪問。與棧相比堆沒有任何訪問限制，堆就像床上的舊衣服，我們並沒有花時間去整理，那是因為可以隨時找到一件我們需要的衣服，而棧就像儲物櫃裡堆疊的鞋盒，我們只能從最頂層的盒子開始取，直到發現那隻合適的。

[heapvsstack1.gif]

以上圖片並不是記憶體中真實的表現形式，但能夠幫助我們區分棧和堆。

棧是自行維護的，也就是說記憶體自動維護棧，當棧頂的盒子不再被使用，它將被丟擲。相反的，堆需要考慮垃圾回收，垃圾回收用於保持堆的整潔性，沒有人願意看到周圍都是贓衣服，那簡直太臭了！

* 棧和堆裡有些什麼？

當我們的程式碼執行的時候，棧和堆中主要放置了四種類型的資料：值型別(Value Type)，引用型別(Reference Type)，指標(Pointer)，指令(Instruction)。

1.值型別：

在C#中，所有被宣告為以下型別的事物被稱為值型別：

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

2.引用型別：

所有的被宣告為以下型別的事物被稱為引用型別：

class 
interface 
delegate 
object 
string ，賦值的時候是複製一份，與引用型別不同

3.指標：

在記憶體管理方案中放置的第三種類型是型別引用，引用通常就是一個指標。我們不會顯示的使用指標，它們由公共語言執行時（CLR）來管理。指標（或引用）是不同於引用型別的，是因為當我們說某個事物是一個引用型別時就意味著我們是通過指標來訪問它的。指標是一塊記憶體空間，而它指向另一個記憶體空間。就像棧和堆一樣，指標也同樣要佔用記憶體空間，但它的值是一個記憶體地址或者為空。

[heapvsstack2.gif]

4.指令：

在後面的文章中你會看到指令是如何工作的...

* 如何決定放哪兒?

這裡有一條黃金規則:

1. 引用型別總是放在堆中。(夠簡單的吧?)

2. 值型別和指標總是放在它們被宣告的地方。(這條稍微複雜點，需要知道棧是如何工作的，然後才能斷定是在哪兒被宣告的。)

就像我們先前提到的，棧是負責儲存我們的程式碼執行(或呼叫)時的路徑。當我們的程式碼開始呼叫一個方法時,將放置一段編碼指令(在方法中)到棧上,緊接著放置方法的引數，然後程式碼執行到方法中的被“壓棧”至棧頂的變數位置。通過以下例子很容易理解...

下面是一個方法（Method）:

           public int AddFive(int pValue)
          {
                int result;
                result = pValue + 5;
                return result;
          }

現在就來看看在棧頂發生了些什麼，記住我們所觀察的棧頂下實際已經壓入了許多別的內容。

首先方法（只包含需要執行的邏輯位元組，即執行該方法的指令，而非方法體內的資料）入棧，緊接著是方法的引數入棧。（我們將在後面討論更多的引數傳遞）

[heapvsstack3.gif]

接著，控制（即執行方法的執行緒）被傳遞到堆疊中AddFive()的指令上，

[heapvsstack4.gif]

當方法執行時，我們需要在棧上為“result”變數分配一些記憶體，

[heapvsstack5.gif]

The method finishes execution and our result is returned.
方法執行完成，然後方法的結果被返回。

[heapvsstack6.gif]

通過將棧指標指向AddFive()方法曾使用的可用的記憶體地址，所有在棧上的該方法所使用記憶體都被清空，且程式將自動回到棧上最初的方法呼叫的位置(在本例中不會看到)。

[heapvsstack7.gif]

在這個例子中，我們的"result"變數是被放置在棧上的，事實上，當值型別資料在方法體中被宣告時，它們都是被放置在棧上的。

值型別資料有時也被放置在堆上。記住這條規則--值型別總是放在它們被宣告的地方。好的，如果一個值型別資料在方法體外被宣告，且存在於一個引用型別中，那麼它將被堆中的引用型別所取代。

來看另一個例子：

假如我們有這樣一個MyInt類（它是引用型別因為它是一個類型別）：

          public class MyInt
          {          
             public int MyValue;
          }

然後執行下面的方法:

          public MyInt AddFive(int pValue)
          {
                MyInt result = new MyInt();
                result.MyValue = pValue + 5;
                return result;
          }

就像前面提到的，方法及方法的引數被放置到棧上，接下來，控制被傳遞到堆疊中AddFive()的指令上。

[heapvsstack8.gif]

接著會出現一些有趣的現象...

因為"MyInt"是一個引用型別,它將被放置在堆上,同時在棧上生成一個指向這個堆的指標引用。

[heapvsstack9.gif]

在AddFive()方法被執行之後，我們將清空...

[heapvsstack10.gif]

我們將剩下孤獨的MyInt物件在堆中（棧中將不會存在任何指向MyInt物件的指標!）

[heapvsstack11.gif]

這就是垃圾回收器（後簡稱GC）起作用的地方。當我們的程式達到了一個特定的記憶體閥值(32bit 機給每個程式分配4G記憶體)，我們需要更多的堆空間的時候，GC開始起作用。GC將停止所有正在執行的執行緒，找出在堆中存在的所有不再被主程式訪問的物件，並刪除它們。然後GC會重新組織堆中所有剩下的物件來節省空間，並調整棧和堆中所有與這些物件相關的指標。你肯定會想到這個過程非常耗費效能，所以這時你就會知道為什麼我們需要如此重視棧和堆裡有些什麼，特別是在需要編寫高效能的程式碼時。

Ok... 這太棒了, 當它是如何影響我的？

Good question. 

當我們使用引用型別時，我們實際是在處理該型別的指標，而非該型別本身。當我們使用值型別時，我們是在使用值型別本身。聽起來很迷糊吧？

同樣，例子是最好的描述。

假如我們執行以下的方法：

          public int ReturnValue()
          {
                int x = new int();
                x = 3;
                int y = new int();
                y = x;      
                y = 4;          
                return x;
          }

我們將得到值3，很簡單，對吧？

假如我們首先使用MyInt類

     public class MyInt
          {
                public int MyValue;
          }

接著執行以下的方法：

          public int ReturnValue2()
          {
                MyInt x = new MyInt();
                x.MyValue = 3;
                MyInt y = new MyInt();
                y = x;                 
                y.MyValue = 4;              
                return x.MyValue;
          }

我們將得到什麼？...    4!

為什麼？...  x.MyValue怎麼會變成4了呢？...  看看我們所做的然後就知道是怎麼回事了：

在第一例子中，一切都像計劃的那樣進行著：

          public int ReturnValue()
          {
                int x = 3;
                int y = x;    
                y = 4;
                return x;
          }

[heapvsstack12.gif]

在第二個例子中，我們沒有得到"3"是因為變數"x"和"y"都同時指向了堆中相同的物件。
          public int ReturnValue2()
          {
                MyInt x;
                x.MyValue = 3;
                MyInt y;
                y = x;                
                y.MyValue = 4;
                return x.MyValue;
          }

[heapvsstack13.gif]

希望以上內容能夠使你對C#中的值型別和引用型別的基本區別有一個更好的認識，並且對指標及指標是何時被使用的有一定的基本瞭解。在系列的下一個部分，我們將深入記憶體管理並專門討論方法引數。

To be continued...

.NET中棧和堆的比較 #2

原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory2B01142006125918PM/csharp_memory2B.aspx


儘管在.NET framework下我們並不需要擔心記憶體管理和垃圾回收(Garbage Collection)，但是我們還是應該瞭解它們，以優化我們的應用程式。同時，還需要具備一些基礎的記憶體管理工作機制的知識，這樣能夠有助於解釋我們日常程式編寫中的變數的行為。在本文中我將講解我們必須要注意的方法傳參的行為。

在第一部分裡我介紹了棧和堆的基本功能，還介紹到了在程式執行時值型別和引用型別是如何分配的，而且還談到了指標。

* 引數，大問題

這裡有一個程式碼執行時的詳細介紹，我們將深入第一部分出現的方法呼叫過程...

當我們呼叫一個方法時，會發生以下的事情：

1.方法執行時，首先在棧上為物件例項中的方法分配空間，然後將方法拷貝到棧上（此時的棧被稱為幀），但是該空間中只存放了執行方法的指令，並沒有方法內的資料項。

3.方法引數的分配和拷貝是需要空間的，這一點是我們需要進一步注意。

示例程式碼如下:

          public int AddFive(int pValue)
          {
                int result;
                result = pValue + 5;
                return result;
          }

此時棧開起來是這樣的:

就像第一部分討論的那樣，放在棧上的引數是如何被處理的，需要看看它是值型別還是引用型別。值型別的值將被拷貝到棧上，而引用型別的引用（或者說指標）將被拷貝到棧上。

* 值型別傳遞

首先，當我們傳遞一個值型別引數時，棧上被分配好一個新的空間，然後該引數的值被拷貝到此空間中。

來看下面的方法：

     class Class1
     {

          public void Go()
          {

              int x = 5;
              
              AddFive(x);

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

          public int AddFive(int pValue)
          {

              pValue += 5;

              return pValue;
          }
     }

方法Go()被放置到棧上，然後執行，整型變數"x"的值"5"被放置到棧頂空間中。

然後AddFive()方法被放置到棧頂上，接著方法的形參值被拷貝到棧頂，且該形參的值就是"x"的拷貝。

當AddFive()方法執行完成之後，執行緒就通過預先放置的指令返回到Go()方法的地址，然後從棧頂依次將變數pValue和方法AddFive()移除掉:

所以我們的程式碼輸出的值是"5"，對吧？這裡的關鍵之處就在於任何傳入方法的值型別引數都是複製拷貝的，所以原始變數中的值是被保留下來而沒有被改變的。

必須注意的是，如果我們要將一個非常大的值型別資料(如資料量大的struct型別)入棧，它會佔用非常大的記憶體空間，而且會佔有過多的處理器週期來進行拷貝複製。棧並沒有無窮無盡的空間，它就像在水龍頭下盛水的杯子，隨時可能溢位。struct是一個能夠存放大量資料的值型別成員，我們必須小心地使用。

這裡有一個存放大資料型別的struct:

           public struct MyStruct

           {

               long a, b, c, d, e, f, g, h, i, j, k, l, m;

           }

來看看當我們執行了Go()和DoSometing()方法時會發生什麼：

          public void Go()

          {

             MyStruct x = new MyStruct();

             DoSomething(x);

          }

           public void DoSomething(MyStruct pValue)
           
           {
           
                    // DO SOMETHING HERE....

           }

這將會非常的低效。想象我們要是傳遞2000次MyStruct,你就會明白程式是怎麼癱瘓掉的了。

那麼我們應該如何解決這個問題？可以通過下列方式來傳遞原始值的引用：

          public void Go()

          {

             MyStruct x = new MyStruct();

             DoSomething(ref x);

          }

           public struct MyStruct

           {

               long a, b, c, d, e, f, g, h, i, j, k, l, m;

           }

           public void DoSomething(ref MyStruct pValue)

           {

                    // DO SOMETHING HERE....

           }

通過這種方式我們能夠提高記憶體中物件分配的效率。

唯一需要注意的是，在我們通過引用傳遞值型別時我們會修改該值型別的值，也就是說pValue值的改變會引起x值的改變。執行以下程式碼，我們的結果會變成"123456"，這是因為pValue實際指向的記憶體空間與ｘ變數宣告的記憶體空間是一致的。
          
          public void Go()

          {

             MyStruct x = new MyStruct();

             x.a = 5;

             DoSomething(ref x);

             Console.WriteLine(x.a.ToString());

          }

          public void DoSomething(ref MyStruct pValue)

          {

                   pValue.a = 12345;

          }

* 引用型別傳遞

傳遞引用型別引數的情況類似於先前例子中通過引用來傳遞值型別的情況。

如果我們使用引用型別：

           public class MyInt

           {

               public int MyValue;

           }

然後呼叫Go()方法，MyInt物件將放置在堆上：

          public void Go()

          {

             MyInt x = new MyInt();              

          }

如果我們執行下面的Go()方法：

          public void Go()

          {

             MyInt x = new MyInt();

             x.MyValue = 2;

             DoSomething(x);

             Console.WriteLine(x.MyValue.ToString());

          }

           public void DoSomething(MyInt pValue)

           {

               pValue.MyValue = 12345;

           }

將發生這樣的事情...

1.方法Go()入棧
2.Go()方法中的變數x入棧
3.方法DoSomething()入棧
4.引數pValue入棧
5.ｘ的值(MyInt物件的在棧中的指標地址)被拷貝到pValue中

因此，當我們通過MyInt型別的pValue來改變堆中MyInt物件的MyValue成員值後，接著又使用指向該物件的另一個引用ｘ來獲取了其MyValue成員值，得到的值就變成了"12345"。

而更有趣的是，當我們通過引用來傳遞一個引用型別時，會發生什麼？

讓我們來檢驗一下。假如我們有一個"Thing"類和兩個繼承於"Thing"的"Animal"和"Vegetable" 類：
           
           public class Thing

           {

           }

           public class Animal:Thing

           {

               public int Weight;

           }

           public class Vegetable:Thing

           {

               public int Length;

           }

然後執行下面的Go()方法：

          public void Go()

          {

             Thing x = new Animal();

             Switcharoo(ref x);

              Console.WriteLine(

                "x is Animal    :   "

                + (x is Animal).ToString());

              Console.WriteLine(

                  "x is Vegetable :   "

                  + (x is Vegetable).ToString());

          }

           public void Switcharoo(ref Thing pValue)

           {

               pValue = new Vegetable();

           }

變數ｘ被返回為Vegetable型別。

x is Animal    :   False
x is Vegetable :   True

讓我們來看看發生了什麼：

1.Go()方法入棧
2.x指標入棧
3.Animal物件例項化到堆中
4.Switcharoo()方法入棧
5.pValue入棧且指向ｘ

6.Vegetable物件例項化到堆中
7.x的值通過被指向Vegetable物件地址的pValue值所改變。

如果我們不使用Thing的引用，相反的，我們得到結果變數x將會是Animal型別的。

如果以上程式碼對你來說沒有什麼意義，那麼請繼續看看我的文章中關於引用變數的介紹，這樣能夠對引用型別的變數是如何工作的會有一個更好的理解。

我們看到了記憶體是怎樣處理引數傳遞的，在系列的下一部分中，我們將看看棧中的引用變數發生了些什麼，然後考慮當我們拷貝物件時是如何來解決某些問題的。

To be continued...

.NET中棧和堆的比較 #3

原文出處
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...

終於翻完了第四篇，本來每次都是週末發的，可惜上週末有些事兒沒忙過來，所以今天中午給補上來。不知道這套文章還能不能繼續了，因為作者也只寫到了第四篇，連他都不知道第五篇什麼時候出得來...

原文出處
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

在物件建立期間，所有帶有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

}

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是如何發現問題並清除它們的。