本文轉自：C#開發園地 原文翻譯的地址：
http://www.cnblogs.com/c2303191/articles/1065675.html

?

?

壓棧(入棧)=執行方法中的指令 .NET中棧和堆的比較1 原文出處：
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）起作用的地方。當我們的程序達到了一個特定的內存閥值，我們需要更多的堆空間的時候，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;
??????????}

此時棧開起來是這樣的:
[heapvsstack2-1.gif]
就像第一部分討論的那樣，放在棧上的參數是如何被處理的，需要看看它是值類型還是引用類型。值類型的值將被拷貝到棧上，而引用類型的引用（或者說指針）將被拷貝到棧上。

*?值類型傳遞

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

來看下面的方法：

?????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"被放置到棧頂空間中。
[heapvsstack2-2.gif]
然后AddFive()方法被放置到棧頂上，接著方法的形參值被拷貝到棧頂，且該形參的值就是"x"的拷貝。
[heapvsstack2-3.gif]
當AddFive()方法執行完成之后，線程就通過預先放置的指令返回到Go()方法的地址，然后從棧頂依次將變量pValue和方法AddFive()移除掉:
[heapvsstack2-4.gif]
所以我們的代碼輸出的值是"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....

???????????}
[heapvsstack2-5.gif]
這將會非常的低效。想象我們要是傳遞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....

???????????}

通過這種方式我們能夠提高內存中對象分配的效率。
[heapvsstack2-6.gif]
唯一需要注意的是，在我們通過引用傳遞值類型時我們會修改該值類型的值，也就是說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;

???????????}
[heapvsstack2-7.gif]
然后調用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;

???????????}

將發生這樣的事情...
[heapvsstack2-8.gif]
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

讓我們來看看發生了什么：
[heapvsstack2-9.gif]
1.Go()方法入棧
2.x指針入棧
3.Animal對象實例化到堆中
4.Switcharoo()方法入棧
5.pValue入棧且指向ｘ
[heapvsstack2-10.gif]
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類的成員，所以它們都被放在了堆上。
[heapvsstack3-1gif]
當我們執行以下的方法時：

???????????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)腳上了，很明顯出錯了。你想知道這是為什么嗎？我們再來看看堆就明白了。
[heapvsstack3-2gif]
由于我們現在使用的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

這就是我們想要的。
[heapvsstack3-3gif]
在通常情況下，我們應該"克隆"引用類型，"拷貝"值類型。(這樣，在你調試以上介紹的情況中的問題時，會減少你買來控制頭痛的阿司匹林的藥量)
在頭痛減少的激烈下，我們可以更進一步地使用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中棧和堆的比較4 終于翻完了第四篇，本來每次都是周末發的，可惜上周末有些事兒沒忙過來，所以今天中午給補上來。不知道這套文章還能不能繼續了，因為作者也只寫到了第四篇，連他都不知道第五篇什么時候出得來...

原文出處
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寄存器直接指向的內存地址上的東西必須得保留。
[Stacking_Heaping1.gif]
在以上圖片中，托管堆中的對象1、3、5都被根所引用，其中1和5時直接被引用，而3時在遞歸查找時被發現的。像我們之前的假設一樣，對象1是我們的電視機，對象3是我們的遙控器。在所有對象被遞歸查找出來之后我們將進入下一步--壓縮。

*?壓縮

我們現在已經繪制出哪些是我們需要保留的對象，那么我們就能夠通過移動"保留對象"來對托管堆進行整理。
[Stacking_Heaping2.gif]
幸運的是，在我們的房間里沒有必要為了放入別的東西而去清理空間。因為對象2已經不再需要了，所以GC會將對象3移下來，同時修復它指向對象1的指針。
[Stacking_Heaping3.gif]
然后，GC將對象5也向下移,
[Stacking_Heaping4.gif]
現在所有的東西都被清理干凈了，我們只需要寫一張便簽貼到壓縮后的堆上，讓Claire(指CLR)知道在哪兒放入新的對象就行了。
[Stacking_Heaping5.gif]
理解GC的本質會讓我們明白對象的移動是非常費力的。可以看出，假如我們能夠減少需要移動的物品大小是非常有意義的，通過更少的拷貝動作能夠使我們提升整個GC的處理性能。

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

作為負責垃圾回收的人員，有一個容易出現入的問題是在打掃房間時如何處理車里的東西，當我們打掃衛生時，我們需要將所有物品清理干凈。那家里的臺燈和車里的電池怎么辦？

在一些情況下，GC需要執行代碼來清理非托管資源(如文件，數據庫連接，網絡連接等)，一種可能的方式是通過finalizer來進行處理。
class?Sample

{

??????????~Sample()

??????????{

????????????????????//?FINALIZER:?CLEAN?UP?HERE

??????????}

}

在對象創建期間，所有帶有finalizer的對象都將被添加到一個finalizer隊列中。對象1、4、5都有finalizer，且都已在finalizer隊列當中。讓我們來看看當對象2和4在應用程序中不再被引用，且系統正準備進行垃圾回收時會發生些什么。
[Stacking_Heaping6.gif]
對象2會像通常情況下那樣被垃圾回收器回收，但是當我們處理對象4時，GC發現它存在于finalizer隊列中，那么GC就不會回收對象4的內存空間，而是將對象4的finalizer移到一個叫做"freachable"的特殊隊列中。
[Stacking_Heaping7.gif]
有一個專門的線程來執行freachable隊列中的項，對象4的finalizer一旦被該線程所處理，就將從freachable隊列中被移除，然后對象4就等待被回收。
[Stacking_Heaping8.gif]
因此對象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()方法都會占用內存空間。
[Stacking_Heaping9.gif]
一種更高效的方式是采用靜態方法，這樣我們只需要在內存中放置唯一的SayHello()方法，而不論存在多少個Dude類實例。因為靜態成員不是實例成員，我們不能使用this指針來進行方法的引用。
class?Dude

{

??????????private?string?_Name?=?"Don";

?

??????????public?static?void?SayHello(string?pName)

??????????{

????????????????????Console.WriteLine(pName?+?"?says?Hello");

??????????}

}?

?
[Stacking_Heaping10.gif]
請注意我們在傳遞變量時棧上發生了些什么(可以參看<第二部分>)。我們需要通過例子的看看是否需要使用靜態方法來提升性能。例如,一個靜態方法需要很多參數而且沒有什么復雜的邏輯，那么在使用靜態方法時我們可能會降低性能。

*?靜態變量：注意了！

對于靜態變量，有兩件事情我們需要注意。假如我們的類中有一個靜態方法用于返回一個唯一值，而下面的實現會造成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...

?

總結

以上是生活随笔為你收集整理的.NET中栈和堆的比较【转自：c#开发园地】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。