盡管在.Net framework下我們並不需要擔心內存管理和垃圾回收(Garbage Collection)，但是我們還是應該了解它們，以優化我們的應用程序。同時，還需要具備一些基礎的內存管理工作機制的知識，這樣能夠有助於解釋我們日常程序編寫中的變量的行為。在本文中我將講解棧和堆的基本知識，變量類型以及為什麼一些變量能夠按照它們自己的方式工作。
在.Net framework環境下，當我們的代碼執行時，內存中有兩個地方用來存儲這些代碼。假如你不曾了解，那就讓我來給你介紹棧(Stack)和堆(Heap)。棧和堆都用來幫助我們運行代碼的，它們駐留在機器內存中，且包含所有代碼執行所需要的信息。
* 棧vs堆：有什麼不同？
棧負責保存我們的代碼執行（或調用）路徑,而堆則負責保存對象（或者說數據，接下來將談到很多關於堆的問題）的路徑。
可以將棧想象成一堆從頂向下堆疊的盒子。當每調用一次方法時，我們將應用程序中所要發生的事情記錄在棧頂的一個盒子中,而我們每次只能夠使用棧頂的那個盒子。當我們棧頂的盒子被使用完之後，或者說方法執行完畢之後，我們將拋開這個盒子然後繼續使用棧頂上的新盒子。堆的工作原理比較相似，但大多數時候堆用作保存信息而非保存執行路徑，因此堆能夠在任意時間被訪問。與棧相比堆沒有任何訪問限制，堆就像床上的舊衣服，我們並沒有花時間去整理，那是因為可以隨時找到一件我們需要的衣服，而棧就像儲物櫃裡堆疊的鞋盒，我們只能從最頂層的盒子開始取，直到發現那只合適的。
以上圖片並不是內存中真實的表現形式，但能夠幫助我們區分棧和堆。
棧是自行維護的，也就是說內存自動維護棧，當棧頂的盒子不再被使用，它將被拋出。相反的，堆需要考慮垃圾回收，垃圾回收用於保持堆的整潔性，沒有人願意看到周圍都是贓衣服，那簡直太臭了！
* 棧和堆裡有些什麼？
當我們的代碼執行的時候，棧和堆中主要放置了四種類型的數據：值類型(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）來管理。指針（或引用）是不同於引用類型的，是因為當我們說某個事物是一個引用類型時就意味著我們是通過指針來訪問它的。指針是一塊內存空間，而它指向另一個內存空間。就像棧和堆一樣，指針也同樣要占用內存空間，但它的值是一個內存地址或者為空。
4.指令：
在後面的文章中你會看到指令是如何工作的...
* 如何決定放哪兒?
這裡有一條黃金規則:
1. 引用類型總是放在堆中。(夠簡單的吧?)
2. 值類型和指針總是放在它們被聲明的地方。(這條稍微復雜點，需要知道棧是如何工作的，然後才能斷定是在哪兒被聲明的。)
就像我們先前提到的，棧是負責保存我們的代碼執行(或調用)時的路徑。當我們的代碼開始調用一個方法時,將放置一段編碼指令(在方法中)到棧上,緊接著放置方法的參數，然後代碼執行到方法中的被“壓棧”至棧頂的變量位置。
通過以下例子很容易理解...
下面是一個方法（Method）:
復制C#代碼保存代碼public int AddFive(int pValue)
{
int result;
result = pValue + 5;
return result;
}
現在就來看看在棧頂發生了些什麼，記住我們所觀察的棧頂下實際已經壓入了許多別的內容。
首先方法（只包含需要執行的邏輯字節，即執行該方法的指令，而非方法體內的數據）入棧，緊接著是方法的參數入棧。（我們將在後面討論更多的參數傳遞）
接著，控制（即執行方法的線程）被傳遞到堆棧中AddFive()的指令上，
當方法執行時，我們需要在棧上為“result”變量分配一些內存，
The method finishes execution and our result is returned.
方法執行完成，然後方法的結果被返回。
通過將棧指針指向AddFive()方法曾使用的可用的內存地址，所有在棧上的該方法所使用內存都被清空，且程序將自動回到棧上最初的方法調用的位置(在本例中不會看到)。
在這個例子中，我們的"result"變量是被放置在棧上的，事實上，當值類型數據在方法體中被聲明時，它們都是被放置在棧上的。
值類型數據有時也被放置在堆上。記住這條規則--值類型總是放在它們被聲明的地方。好的，如果一個值類型數據在方法體外被聲明，且存在於一個引用類型中，那麼它將被堆中的引用類型所取代。
來看另一個例子：
假如我們有這樣一個MyInt類（它是引用類型因為它是一個類類型）：
復制C#代碼保存代碼public class MyInt
{
public int MyValue;
}
然後執行下面的方法:
復制C#代碼保存代碼public MyInt AddFive(int pValue)
{
MyInt result = new MyInt();
result.MyValue = pValue + 5;
return result;
}
就像前面提到的，方法及方法的參數被放置到棧上，接下來，控制被傳遞到堆棧中AddFive()的指令上。
接著會出現一些有趣的現象...
因為"MyInt"是一個引用類型,它將被放置在堆上,同時在棧上生成一個指向這個堆的指針引用。
在AddFive()方法被執行之後，我們將清空...
我們將剩下孤獨的MyInt對象在堆中（棧中將不會存在任何指向MyInt對象的指針!）
這就是垃圾回收器（後簡稱GC）起作用的地方。當我們的程序達到了一個特定的內存閥值，我們需要更多的堆空間的時候，GC開始起作用。GC將停止所有正在運行的線程，找出在堆中存在的所有不再被主程序訪問的對象，並刪除它們。然後GC會重新組織堆中所有剩下的對象來節省空間，並調整棧和堆中所有與這些對象相關的指針。你肯定會想到這個過程非常耗費性能，所以這時你就會知道為什麼我們需要如此重視棧和堆裡有些什麼，特別是在需要編寫高性能的代碼時。
Ok... 這太棒了, 當它是如何影響我的？
Good question.
當我們使用引用類型時，我們實際是在處理該類型的指針，而非該類型本身。當我們使用值類型時，我們是在使用值類型本身。聽起來很迷糊吧？
同樣，例子是最好的描述。
假如我們執行以下的方法：
復制C#代碼保存代碼public int ReturnValue()
{
int x = new int();
x = 3;
int y = new int();
原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.ASPx
NET中棧和堆的區別（比較）（2）
2007-10-16 16:17
盡管在.Net framework下我們並不需要擔心內存管理和垃圾回收(Garbage Collection)，但是我們還是應該了解它們，以優化我們的應用程序。同時，還需要具備一些基礎的內存管理工作機制的知識，這樣能夠有助於解釋我們日常程序編寫中的變量的行為。在本文中我將講解我們必須要注意的方法傳參的行為。
在第一部分裡我介紹了棧和堆的基本功能，還介紹到了在程序執行時值類型和引用類型是如何分配的，而且還談到了指針。
* 參數，大問題
這裡有一個代碼執行時的詳細介紹，我們將深入第一部分出現的方法調用過程...
當我們調用一個方法時，會發生以下的事情：
1.方法執行時，首先在棧上為對象實例中的方法分配空間，然後將方法拷貝到棧上（此時的棧被稱為幀），但是該空間中只存放了執行方法的指令，並沒有方法內的數據項。
2.方法的調用地址(或者說指針)被放置到棧上，一般來說是一個GOTO指令，使我們能夠在方法執行完成之後，知道回到哪個地方繼續執行程序。（最好能理解這一點，但並不是必須的，因為這並不會影響我們的編碼）
3.方法參數的分配和拷貝是需要空間的，這一點是我們需要進一步注意。
4.控制此時被傳遞到了幀上，然後線程開始執行我們的代碼。因此有另一個方法叫做"調用棧"。
示例代碼如下:
復制C#代碼保存代碼public int AddFive(int pValue)
{
int result;
result = pValue + 5;
return result;
}
此時棧開起來是這樣的:
就像第一部分討論的那樣，放在棧上的參數是如何被處理的，需要看看它是值類型還是引用類型。值類型的值將被拷貝到棧上，而引用類型的引用（或者說指針）將被拷貝到棧上。
* 值類型傳遞
首先，當我們傳遞一個值類型參數時，棧上被分配好一個新的空間，然後該參數的值被拷貝到此空間中。
來看下面的方法：
復制C#代碼保存代碼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:
復制C#代碼保存代碼public struct MyStruct
{
long a, b, c, d, e, f, g, h, i, j, k, l, m;
}
來看看當我們執行了Go()和DOSometing()方法時會發生什麼：
復制C#代碼保存代碼public void Go()
{
MyStruct x = new MyStruct();
DOSomething(x);
}
public void DOSomething(MyStruct pValue)
{
// DO SOMETHING HERE....
}
這將會非常的低效。想象我們要是傳遞2000次MyStruct,你就會明白程序是怎麼癱瘓掉的了。
那麼我們應該如何解決這個問題？可以通過下列方式來傳遞原始值的引用：
復制C#代碼保存代碼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實際指向的內存空間與ｘ變量聲明的內存空間是一致的。
復制C#代碼保存代碼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;
}
* 引用類型傳遞
傳遞引用類型參數的情況類似於先前例子中通過引用來傳遞值類型的情況。
如果我們使用引用類型：
復制C#代碼保存代碼public class MyInt
{
public int MyValue;
}
然後調用Go()方法，MyInt對象將放置在堆上：
復制C#代碼保存代碼public void Go()
{
MyInt x = new MyInt();
}
如果我們執行下面的Go()方法：
復制C#代碼保存代碼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" 類：
復制C#代碼保存代碼public class Thing
{
}
public class Animal : Thing
{
public int Weight;
}
public class Vegetable : Thing
{
public int Length;
}
然後執行下面的Go()方法：
復制C#代碼保存代碼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...
原文出處：
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory2B01142006125918PM/csharp_memory2B.ASPx
盡管在.Net framework下我們並不需要擔心內存管理和垃圾回收(Garbage Collection)，但是我們還是應該了解它們，以優化我們的應用程序。同時，還需要具備一些基礎的內存管理工作機制的知識，這樣能夠有助於解釋我們日常程序編寫中的變量的行為。在本文中我們將涉及到堆中引用變量引起的問題，以及如何使用ICloneable接口來解決該問題。
需要回顧堆棧基礎，值類型和引用類型，請轉到第一部分和第二部分
第一部分
http://agassi001.cnblogs.com/archive/2006/05/10/396574.Html
第二部分
http://agassi001.cnblogs.com/archive/2006/05/13/399080.Html
* 副本並不是真的副本
為了清楚的闡明問題，讓我們來比較一下當堆中存在值類型和引用類型時都發生了些什麼。首先來看看值類型，如下面的類和結構。這裡有一個類Dude，它的成員中有一個string型的Name字段及兩個Shoe類型的字段--RightShoe、LeftShoe，還有一個CopyDude()方法可以很容易地生成新的Dude實例。
復制C#代碼保存代碼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 " +
Left
Shoe.Color + " on my left foot.");
}
}
Dude是引用類型，而且由於結構Shoe的兩個字段是Dude類的成員，所以它們都被放在了堆上。
當我們執行以下的方法時：
復制C#代碼保存代碼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改為引用類型：
復制C#代碼保存代碼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()
復制C#代碼保存代碼public object Clone()
{
}
我們應該在Shoe類中這樣實現：
復制C#代碼保存代碼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()方法中我們需要克隆鞋子而非拷貝它們：
復制C#代碼保存代碼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()函數時：
復制C#代碼保存代碼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()方法。
復制C#代碼保存代碼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()：
復制C#代碼保存代碼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型對象實際上是被自動克隆過後的。
原文出處
http://www.c-sharpcorner.com/UploadFile/rmcochran/chsarp_memory401152006094206AM/chsarp_memory4.ASPx
NET中棧和堆的區別（比較）（4）
2007-10-16 16:20
可以參看該系列文章的前面部分內容：
Part I
http://agassi001.cnblogs.com/archive/2006/05/10/396574.Html
Part II
http://agassi001.cnblogs.com/archive/2006/05/13/399080.Html
Part III
http://www.cnblogs.com/agassi001/archive/2006/05/20/405018.Html
盡管在.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來進行處理。
復制C#代碼保存代碼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接口中唯一的簽名)。
學網 http://www.xue5.com (本站) [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]
GC在復制大塊內存數據來放到一起時是很容易的，而復制堆中的碎片是很費勁的，所以當我們聲明一個包含許多其他對象的對象時，我們應該在初始化時盡量讓他們在一塊兒。
5. 最後，使用靜態方法來保持對象的輕便也是可行的。
下一次，我們將更加深入GC的處理過程，看看在你的程序執行時GC是如何發現問題並清除它們的。
To be long long continued...
