.NET中栈和堆的比较【转自：c#开发园地】
生活随笔
收集整理的這篇文章主要介紹了
.NET中栈和堆的比较【转自：c#开发园地】
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
本文轉(zhuǎn)自：C#開發(fā)園地 原文翻譯的地址：
http://www.cnblogs.com/c2303191/articles/1065675.html
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覍⒅v解棧和堆的基本知識(shí)，變量類型以及為什么一些變量能夠按照它們自己的方式工作。
在.NET?framework環(huán)境下，當(dāng)我們的代碼執(zhí)行時(shí)，內(nèi)存中有兩個(gè)地方用來存儲(chǔ)這些代碼。假如你不曾了解，那就讓我來給你介紹棧(Stack)和堆(Heap)。棧和堆都用來幫助我們運(yùn)行代碼的，它們駐留在機(jī)器內(nèi)存中，且包含所有代碼執(zhí)行所需要的信息。
*?棧vs堆：有什么不同？
棧負(fù)責(zé)保存我們的代碼執(zhí)行（或調(diào)用）路徑,而堆則負(fù)責(zé)保存對(duì)象（或者說數(shù)據(jù)，接下來將談到很多關(guān)于堆的問題）的路徑。
可以將棧想象成一堆從頂向下堆疊的盒子。當(dāng)每調(diào)用一次方法時(shí)，我們將應(yīng)用程序中所要發(fā)生的事情記錄在棧頂?shù)囊粋€(gè)盒子中,而我們每次只能夠使用棧頂?shù)哪莻€(gè)盒子。當(dāng)我們棧頂?shù)暮凶颖皇褂猛曛?#xff0c;或者說方法執(zhí)行完畢之后，我們將拋開這個(gè)盒子然后繼續(xù)使用棧頂上的新盒子。堆的工作原理比較相似，但大多數(shù)時(shí)候堆用作保存信息而非保存執(zhí)行路徑，因此堆能夠在任意時(shí)間被訪問。與棧相比堆沒有任何訪問限制，堆就像床上的舊衣服，我們并沒有花時(shí)間去整理，那是因?yàn)榭梢噪S時(shí)找到一件我們需要的衣服，而棧就像儲(chǔ)物柜里堆疊的鞋盒，我們只能從最頂層的盒子開始取，直到發(fā)現(xiàn)那只合適的。
[heapvsstack1.gif]
以上圖片并不是內(nèi)存中真實(shí)的表現(xiàn)形式，但能夠幫助我們區(qū)分棧和堆。
棧是自行維護(hù)的，也就是說內(nèi)存自動(dòng)維護(hù)棧，當(dāng)棧頂?shù)暮凶硬辉俦皇褂?#xff0c;它將被拋出。相反的，堆需要考慮垃圾回收，垃圾回收用于保持堆的整潔性，沒有人愿意看到周圍都是贓衣服，那簡(jiǎn)直太臭了！
*?棧和堆里有些什么？
當(dāng)我們的代碼執(zhí)行的時(shí)候，棧和堆中主要放置了四種類型的數(shù)據(jù)：值類型(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.指針：
在內(nèi)存管理方案中放置的第三種類型是類型引用，引用通常就是一個(gè)指針。我們不會(huì)顯示的使用指針，它們由公共語言運(yùn)行時(shí)（CLR）來管理。指針（或引用）是不同于引用類型的，是因?yàn)楫?dāng)我們說某個(gè)事物是一個(gè)引用類型時(shí)就意味著我們是通過指針來訪問它的。指針是一塊內(nèi)存空間，而它指向另一個(gè)內(nèi)存空間。就像棧和堆一樣，指針也同樣要占用內(nèi)存空間，但它的值是一個(gè)內(nèi)存地址或者為空。
[heapvsstack2.gif]
4.指令：
在后面的文章中你會(huì)看到指令是如何工作的...
*?如何決定放哪兒?
這里有一條黃金規(guī)則:
1.?引用類型總是放在堆中。(夠簡(jiǎn)單的吧?)
2.?值類型和指針總是放在它們被聲明的地方。(這條稍微復(fù)雜點(diǎn)，需要知道棧是如何工作的，然后才能斷定是在哪兒被聲明的。)
就像我們先前提到的，棧是負(fù)責(zé)保存我們的代碼執(zhí)行(或調(diào)用)時(shí)的路徑。當(dāng)我們的代碼開始調(diào)用一個(gè)方法時(shí),將放置一段編碼指令(在方法中)到棧上,緊接著放置方法的參數(shù)，然后代碼執(zhí)行到方法中的被“壓棧”至棧頂?shù)淖兞课恢谩Ｍㄟ^以下例子很容易理解...
下面是一個(gè)方法（Method）:
???????????public?int?AddFive(int?pValue)
??????????{
????????????????int?result;
????????????????result?=?pValue?+?5;
????????????????return?result;
??????????}
現(xiàn)在就來看看在棧頂發(fā)生了些什么，記住我們所觀察的棧頂下實(shí)際已經(jīng)壓入了許多別的內(nèi)容。
首先方法（只包含需要執(zhí)行的邏輯字節(jié)，即執(zhí)行該方法的指令，而非方法體內(nèi)的數(shù)據(jù)）入棧，緊接著是方法的參數(shù)入棧。（我們將在后面討論更多的參數(shù)傳遞）
[heapvsstack3.gif]
接著，控制（即執(zhí)行方法的線程）被傳遞到堆棧中AddFive()的指令上，
[heapvsstack4.gif]
當(dāng)方法執(zhí)行時(shí)，我們需要在棧上為“result”變量分配一些內(nèi)存，
[heapvsstack5.gif]
The?method?finishes?execution?and?our?result?is?returned.
方法執(zhí)行完成，然后方法的結(jié)果被返回。
[heapvsstack6.gif]
通過將棧指針指向AddFive()方法曾使用的可用的內(nèi)存地址，所有在棧上的該方法所使用內(nèi)存都被清空，且程序?qū)⒆詣?dòng)回到棧上最初的方法調(diào)用的位置(在本例中不會(huì)看到)。
[heapvsstack7.gif]
在這個(gè)例子中，我們的"result"變量是被放置在棧上的，事實(shí)上，當(dāng)值類型數(shù)據(jù)在方法體中被聲明時(shí)，它們都是被放置在棧上的。
值類型數(shù)據(jù)有時(shí)也被放置在堆上。記住這條規(guī)則--值類型總是放在它們被聲明的地方。好的，如果一個(gè)值類型數(shù)據(jù)在方法體外被聲明，且存在于一個(gè)引用類型中，那么它將被堆中的引用類型所取代。
來看另一個(gè)例子：
假如我們有這樣一個(gè)MyInt類（它是引用類型因?yàn)樗且粋€(gè)類類型）：
??????????public?class?MyInt
??????????{?????????
?????????????public?int?MyValue;
??????????}
然后執(zhí)行下面的方法:
??????????public?MyInt?AddFive(int?pValue)
??????????{
????????????????MyInt?result?=?new?MyInt();
????????????????result.MyValue?=?pValue?+?5;
????????????????return?result;
??????????}
就像前面提到的，方法及方法的參數(shù)被放置到棧上，接下來，控制被傳遞到堆棧中AddFive()的指令上。
[heapvsstack8.gif]
接著會(huì)出現(xiàn)一些有趣的現(xiàn)象...
因?yàn)?/span>"MyInt"是一個(gè)引用類型,它將被放置在堆上,同時(shí)在棧上生成一個(gè)指向這個(gè)堆的指針引用。
[heapvsstack9.gif]
在AddFive()方法被執(zhí)行之后，我們將清空...
[heapvsstack10.gif]
我們將剩下孤獨(dú)的MyInt對(duì)象在堆中（棧中將不會(huì)存在任何指向MyInt對(duì)象的指針!）
[heapvsstack11.gif]
這就是垃圾回收器（后簡(jiǎn)稱GC）起作用的地方。當(dāng)我們的程序達(dá)到了一個(gè)特定的內(nèi)存閥值，我們需要更多的堆空間的時(shí)候，GC開始起作用。GC將停止所有正在運(yùn)行的線程，找出在堆中存在的所有不再被主程序訪問的對(duì)象，并刪除它們。然后GC會(huì)重新組織堆中所有剩下的對(duì)象來節(jié)省空間，并調(diào)整棧和堆中所有與這些對(duì)象相關(guān)的指針。你肯定會(huì)想到這個(gè)過程非常耗費(fèi)性能，所以這時(shí)你就會(huì)知道為什么我們需要如此重視棧和堆里有些什么，特別是在需要編寫高性能的代碼時(shí)。
Ok...?這太棒了,?當(dāng)它是如何影響我的？
Good?question.?
當(dāng)我們使用引用類型時(shí)，我們實(shí)際是在處理該類型的指針，而非該類型本身。當(dāng)我們使用值類型時(shí)，我們是在使用值類型本身。聽起來很迷糊吧？
同樣，例子是最好的描述。
假如我們執(zhí)行以下的方法：
??????????public?int?ReturnValue()
??????????{
????????????????int?x?=?new?int();
????????????????x?=?3;
????????????????int?y?=?new?int();
????????????????y?=?x;?????
????????????????y?=?4;?????????
????????????????return?x;
??????????}
我們將得到值3，很簡(jiǎn)單，對(duì)吧？
假如我們首先使用MyInt類
?????public?class?MyInt
??????????{
????????????????public?int?MyValue;
??????????}
接著執(zhí)行以下的方法：
??????????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怎么會(huì)變成4了呢？...??看看我們所做的然后就知道是怎么回事了：
在第一例子中，一切都像計(jì)劃的那樣進(jìn)行著：
??????????public?int?ReturnValue()
??????????{
????????????????int?x?=?3;
????????????????int?y?=?x;???
????????????????y?=?4;
????????????????return?x;
??????????}
[heapvsstack12.gif]
在第二個(gè)例子中，我們沒有得到"3"是因?yàn)樽兞?/span>"x"和"y"都同時(shí)指向了堆中相同的對(duì)象。
??????????public?int?ReturnValue2()
??????????{
????????????????MyInt?x;
????????????????x.MyValue?=?3;
????????????????MyInt?y;
????????????????y?=?x;???????????????
????????????????y.MyValue?=?4;
????????????????return?x.MyValue;
??????????}
[heapvsstack13.gif]
希望以上內(nèi)容能夠使你對(duì)C#中的值類型和引用類型的基本區(qū)別有一個(gè)更好的認(rèn)識(shí)，并且對(duì)指針及指針是何時(shí)被使用的有一定的基本了解。在系列的下一個(gè)部分，我們將深入內(nèi)存管理并專門討論方法參數(shù)。
To?be?continued...
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory2B01142006125918PM/csharp_memory2B.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覍⒅v解我們必須要注意的方法傳參的行為。
在第一部分里我介紹了棧和堆的基本功能，還介紹到了在程序執(zhí)行時(shí)值類型和引用類型是如何分配的，而且還談到了指針。
*?參數(shù)，大問題
這里有一個(gè)代碼執(zhí)行時(shí)的詳細(xì)介紹，我們將深入第一部分出現(xiàn)的方法調(diào)用過程...
當(dāng)我們調(diào)用一個(gè)方法時(shí)，會(huì)發(fā)生以下的事情：
1.方法執(zhí)行時(shí)，首先在棧上為對(duì)象實(shí)例中的方法分配空間，然后將方法拷貝到棧上（此時(shí)的棧被稱為幀），但是該空間中只存放了執(zhí)行方法的指令，并沒有方法內(nèi)的數(shù)據(jù)項(xiàng)。
3.方法參數(shù)的分配和拷貝是需要空間的，這一點(diǎn)是我們需要進(jìn)一步注意。
示例代碼如下:
??????????public?int?AddFive(int?pValue)
??????????{
????????????????int?result;
????????????????result?=?pValue?+?5;
????????????????return?result;
??????????}
此時(shí)棧開起來是這樣的:
[heapvsstack2-1.gif]
就像第一部分討論的那樣，放在棧上的參數(shù)是如何被處理的，需要看看它是值類型還是引用類型。值類型的值將被拷貝到棧上，而引用類型的引用（或者說指針）將被拷貝到棧上。
*?值類型傳遞
首先，當(dāng)我們傳遞一個(gè)值類型參數(shù)時(shí)，棧上被分配好一個(gè)新的空間，然后該參數(shù)的值被拷貝到此空間中。
來看下面的方法：
?????class?Class1
?????{
??????????public?void?Go()
??????????{
??????????????int?x?=?5;
?????????????
??????????????AddFive(x);
??????????????Console.WriteLine(x.ToString());
??????????}
??????????public?int?AddFive(int?pValue)
??????????{
??????????????pValue?+=?5;
??????????????return?pValue;
??????????}
?????}
方法Go()被放置到棧上，然后執(zhí)行，整型變量"x"的值"5"被放置到棧頂空間中。
[heapvsstack2-2.gif]
然后AddFive()方法被放置到棧頂上，接著方法的形參值被拷貝到棧頂，且該形參的值就是"x"的拷貝。
[heapvsstack2-3.gif]
當(dāng)AddFive()方法執(zhí)行完成之后，線程就通過預(yù)先放置的指令返回到Go()方法的地址，然后從棧頂依次將變量pValue和方法AddFive()移除掉:
[heapvsstack2-4.gif]
所以我們的代碼輸出的值是"5"，對(duì)吧？這里的關(guān)鍵之處就在于任何傳入方法的值類型參數(shù)都是復(fù)制拷貝的，所以原始變量中的值是被保留下來而沒有被改變的。
必須注意的是，如果我們要將一個(gè)非常大的值類型數(shù)據(jù)(如數(shù)據(jù)量大的struct類型)入棧，它會(huì)占用非常大的內(nèi)存空間，而且會(huì)占有過多的處理器周期來進(jìn)行拷貝復(fù)制。棧并沒有無窮無盡的空間，它就像在水龍頭下盛水的杯子，隨時(shí)可能溢出。struct是一個(gè)能夠存放大量數(shù)據(jù)的值類型成員，我們必須小心地使用。
這里有一個(gè)存放大數(shù)據(jù)類型的struct:
???????????public?struct?MyStruct
???????????{
???????????????long?a,?b,?c,?d,?e,?f,?g,?h,?i,?j,?k,?l,?m;
???????????}
來看看當(dāng)我們執(zhí)行了Go()和DoSometing()方法時(shí)會(huì)發(fā)生什么：
??????????public?void?Go()
??????????{
?????????????MyStruct?x?=?new?MyStruct();
?????????????DoSomething(x);
??????????}
???????????public?void?DoSomething(MyStruct?pValue)
??????????
???????????{
??????????
????????????????????//?DO?SOMETHING?HERE....
???????????}
[heapvsstack2-5.gif]
這將會(huì)非常的低效。想象我們要是傳遞2000次MyStruct,你就會(huì)明白程序是怎么癱瘓掉的了。
那么我們應(yīng)該如何解決這個(gè)問題？可以通過下列方式來傳遞原始值的引用：
??????????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....
???????????}
通過這種方式我們能夠提高內(nèi)存中對(duì)象分配的效率。
[heapvsstack2-6.gif]
唯一需要注意的是，在我們通過引用傳遞值類型時(shí)我們會(huì)修改該值類型的值，也就是說pValue值的改變會(huì)引起x值的改變。執(zhí)行以下代碼，我們的結(jié)果會(huì)變成"123456"，這是因?yàn)閜Value實(shí)際指向的內(nèi)存空間與ｘ變量聲明的內(nèi)存空間是一致的。
?????????
??????????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;
??????????}
*?引用類型傳遞
傳遞引用類型參數(shù)的情況類似于先前例子中通過引用來傳遞值類型的情況。
如果我們使用引用類型：
???????????public?class?MyInt
???????????{
???????????????public?int?MyValue;
???????????}
[heapvsstack2-7.gif]
然后調(diào)用Go()方法，MyInt對(duì)象將放置在堆上：
??????????public?void?Go()
??????????{
?????????????MyInt?x?=?new?MyInt();??????????????
??????????}
如果我們執(zhí)行下面的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;
???????????}
將發(fā)生這樣的事情...
[heapvsstack2-8.gif]
1.方法Go()入棧
2.Go()方法中的變量x入棧
3.方法DoSomething()入棧
4.參數(shù)pValue入棧
5.ｘ的值(MyInt對(duì)象的在棧中的指針地址)被拷貝到pValue中
因此，當(dāng)我們通過MyInt類型的pValue來改變堆中MyInt對(duì)象的MyValue成員值后，接著又使用指向該對(duì)象的另一個(gè)引用ｘ來獲取了其MyValue成員值，得到的值就變成了"12345"。
而更有趣的是，當(dāng)我們通過引用來傳遞一個(gè)引用類型時(shí)，會(huì)發(fā)生什么？
讓我們來檢驗(yàn)一下。假如我們有一個(gè)"Thing"類和兩個(gè)繼承于"Thing"的"Animal"和"Vegetable"?類：
??????????
???????????public?class?Thing
???????????{
???????????}
???????????public?class?Animal:Thing
???????????{
???????????????public?int?Weight;
???????????}
???????????public?class?Vegetable:Thing
???????????{
???????????????public?int?Length;
???????????}
然后執(zhí)行下面的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
讓我們來看看發(fā)生了什么：
[heapvsstack2-9.gif]
1.Go()方法入棧
2.x指針入棧
3.Animal對(duì)象實(shí)例化到堆中
4.Switcharoo()方法入棧
5.pValue入棧且指向ｘ
[heapvsstack2-10.gif]
6.Vegetable對(duì)象實(shí)例化到堆中
7.x的值通過被指向Vegetable對(duì)象地址的pValue值所改變。
如果我們不使用Thing的引用，相反的，我們得到結(jié)果變量x將會(huì)是Animal類型的。
如果以上代碼對(duì)你來說沒有什么意義，那么請(qǐng)繼續(xù)看看我的文章中關(guān)于引用變量的介紹，這樣能夠?qū)σ妙愋偷淖兞渴侨绾喂ぷ鞯臅?huì)有一個(gè)更好的理解。
我們看到了內(nèi)存是怎樣處理參數(shù)傳遞的，在系列的下一部分中，我們將看看棧中的引用變量發(fā)生了些什么，然后考慮當(dāng)我們拷貝對(duì)象時(shí)是如何來解決某些問題的。
To?be?continued...
http://www.c-sharpcorner.com/UploadFile/rmcochran/chsarp_memory401152006094206AM/chsarp_memory4.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覀儗⑸婕暗蕉阎幸米兞恳鸬膯栴}，以及如何使用ICloneable接口來解決該問題。
需要回顧堆棧基礎(chǔ)，值類型和引用類型，請(qǐng)轉(zhuǎn)到第一部分和第二部分
*?副本并不是真的副本
為了清楚的闡明問題，讓我們來比較一下當(dāng)堆中存在值類型和引用類型時(shí)都發(fā)生了些什么。首先來看看值類型，如下面的類和結(jié)構(gòu)。這里有一個(gè)類Dude，它的成員中有一個(gè)string型的Name字段及兩個(gè)Shoe類型的字段--RightShoe、LeftShoe，還有一個(gè)CopyDude()方法可以很容易地生成新的Dude實(shí)例。
???????????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是引用類型，而且由于結(jié)構(gòu)Shoe的兩個(gè)字段是Dude類的成員，所以它們都被放在了堆上。
[heapvsstack3-1gif]
當(dāng)我們執(zhí)行以下的方法時(shí)：
???????????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());????????????
?
???????????}
我們得到了預(yù)期的結(jié)果：
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.
如果我們將結(jié)構(gòu)Shoe換成引用類型會(huì)發(fā)生什么？問題就在于此。
假如我們將Shoe改為引用類型：
???????????public?class?Shoe{
???????????????public?string?Color;
???????????}
然后在與前面相同的Main()方法中運(yùn)行，再來看看我們的結(jié)果：
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)腳上了，很明顯出錯(cuò)了。你想知道這是為什么嗎？我們?cè)賮砜纯炊丫兔靼琢恕?br /> [heapvsstack3-2gif]
由于我們現(xiàn)在使用的Shoe是引用類型而非值類型，當(dāng)引用類型的內(nèi)容被拷貝時(shí)實(shí)際上只拷貝了該類型的指針(并沒有拷貝實(shí)際的對(duì)象)，我們需要作一些額外的工作來使我們的引用類型能夠像值類型一樣使用。
幸運(yùn)的是.NET?Framework中已經(jīng)有了一個(gè)IClonealbe接口(System.ICloneable)來幫助我們解決問題。使用這個(gè)接口可以規(guī)定所有的?Dude類必須遵守和定義引用類型應(yīng)如何被復(fù)制，以避免出現(xiàn)"共享鞋子"的問題。所有需要被克隆的類都需要使用ICloneable接口，包括Shoe?類。
System.IClonealbe只有一個(gè)方法定義：Clone()
??????????????????public?object?Clone()
??????????????????{
??????????????????}
我們應(yīng)該在Shoe類中這樣實(shí)現(xiàn)：
???????????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()中，我們創(chuàng)建了一個(gè)新的Shoe對(duì)象，克隆了所有引用類型，并拷貝了所有值類型，然后返回了這個(gè)新對(duì)象。你可能注意到了?string類已經(jīng)實(shí)現(xiàn)了ICloneable接口，所以我們可以直接調(diào)用Color.Clone()方法。因?yàn)镃lone()方法返回的是對(duì)象的引用,?所以我們需要在設(shè)置鞋的顏色前重構(gòu)這個(gè)引用。
接著，在我們的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;
????????????????}
現(xiàn)在，當(dāng)我們執(zhí)行Main()函數(shù)時(shí)：
???????????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]
在通常情況下，我們應(yīng)該"克隆"引用類型，"拷貝"值類型。(這樣，在你調(diào)試以上介紹的情況中的問題時(shí)，會(huì)減少你買來控制頭痛的阿司匹林的藥量)
在頭痛減少的激烈下，我們可以更進(jìn)一步地使用Dude類來實(shí)現(xiàn)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());????????????
???????????}
最后的結(jié)果是：
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.
非常好！
比較有意思的是請(qǐng)注意為System.String類分配的操作符("="號(hào)),它實(shí)際上是將string型對(duì)象進(jìn)行克隆，所以你不必?fù)?dān)心會(huì)發(fā)生引用拷貝。盡管如此你還是得注意一下內(nèi)存的膨脹。
如果你重新看一下前面的那些圖，會(huì)發(fā)現(xiàn)string型應(yīng)該是引用類型，所以它應(yīng)該是一個(gè)指針(這個(gè)指針指向堆中的另一個(gè)對(duì)象)，但是為了方便起見，我在圖中將string型表示為值類型(實(shí)際上應(yīng)該是一個(gè)指針)，因?yàn)橥ㄟ^"="號(hào)重新被賦值的string型對(duì)象實(shí)際上是被自動(dòng)克隆過后的。
總結(jié)一下：
通常，如果我們打算將我們的對(duì)象用于拷貝，那么我們的類應(yīng)該實(shí)現(xiàn)IClonealbe借口，這樣能夠使引用類型仿效值類型的行為。從中可以看到，搞清楚我們所使用的變量的類型是非常重要的，因?yàn)樵谥殿愋秃鸵妙愋偷膶?duì)象在內(nèi)存中的分配是有區(qū)別的。
在下一部分內(nèi)容中，會(huì)看到我們是怎樣來減少代碼在內(nèi)存中的"腳印"的，將會(huì)談到期待已久的垃圾回收器(Garbage?Collection)。
To?be?continued...
原文出處
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory_401282006141834PM/csharp_memory_4.aspx
可以參看該系列文章的前面部分內(nèi)容：Part?I，Part?II，Part?III
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覀儗⑸钊肜斫饫厥掌?#xff0c;還有如何利用靜態(tài)類成員來使我們的應(yīng)用程序更高效。
*?更小的步伐?==?更高效的分配
為了更好地理解為什么更小的足跡會(huì)更高效，這需要我們對(duì).NET的內(nèi)存分配和垃圾回收專研得更深一些。
*?圖解:
讓我們來仔細(xì)看看GC。如果我們需要負(fù)責(zé)"清除垃圾"，那么我們需要擬定一個(gè)高效的方案。很顯然，我們需要決定哪些東西是垃圾而哪些不是。
?
為了決定哪些是需要保留的，我們首先假設(shè)所有的東西都不是垃圾(墻角里堆著的舊報(bào)紙，閣樓里貯藏的廢物，壁櫥里的所有東西，等等)。假設(shè)在我們的生活當(dāng)中有兩位朋友：Joseph?Ivan?Thomas(JIT)和Cindy?Lorraine?Richmond(CLR)。Joe和Cindy知道它們?cè)谑褂檬裁?#xff0c;而且給了我們一張列表說明了我們需要需要些什么。我們將初始列表稱之為"根"列表,?因?yàn)槲覀儗⑺米髌鹗键c(diǎn)。我們需要保存一張主列表來記錄出我們家中的必備物品。任何能夠使必備物品正常工作或使用的東西也將被添加到列表中來(如果我們要看電視，那么就不能扔掉遙控器，所以遙控器將被添加到列表。如果我們要使用電腦，那么鍵盤和顯示器就得添加到列表)。
這就是GC如何保存我們的物品的，它從即時(shí)編譯器(JIT)和通用語言運(yùn)行時(shí)(CLR)中獲得"根"對(duì)象引用的列表，然后遞歸地搜索出其他對(duì)象引用來建立一張我們需要保存的物品的圖表。
根包括：
*?全局/靜態(tài)指針。為了使我們的對(duì)象不被垃圾回收掉的一種方式是將它們的引用保存在靜態(tài)變量中。
*?棧上的指針。我們不想丟掉應(yīng)用程序中需要執(zhí)行的線程里的東西。
*?CPU寄存器指針。托管堆中哪些被CPU寄存器直接指向的內(nèi)存地址上的東西必須得保留。
[Stacking_Heaping1.gif]
在以上圖片中，托管堆中的對(duì)象1、3、5都被根所引用，其中1和5時(shí)直接被引用，而3時(shí)在遞歸查找時(shí)被發(fā)現(xiàn)的。像我們之前的假設(shè)一樣，對(duì)象1是我們的電視機(jī)，對(duì)象3是我們的遙控器。在所有對(duì)象被遞歸查找出來之后我們將進(jìn)入下一步--壓縮。
*?壓縮
我們現(xiàn)在已經(jīng)繪制出哪些是我們需要保留的對(duì)象，那么我們就能夠通過移動(dòng)"保留對(duì)象"來對(duì)托管堆進(jìn)行整理。
[Stacking_Heaping2.gif]
幸運(yùn)的是，在我們的房間里沒有必要為了放入別的東西而去清理空間。因?yàn)閷?duì)象2已經(jīng)不再需要了，所以GC會(huì)將對(duì)象3移下來，同時(shí)修復(fù)它指向?qū)ο?的指針。
[Stacking_Heaping3.gif]
然后，GC將對(duì)象5也向下移,
[Stacking_Heaping4.gif]
現(xiàn)在所有的東西都被清理干凈了，我們只需要寫一張便簽貼到壓縮后的堆上，讓Claire(指CLR)知道在哪兒放入新的對(duì)象就行了。
[Stacking_Heaping5.gif]
理解GC的本質(zhì)會(huì)讓我們明白對(duì)象的移動(dòng)是非常費(fèi)力的。可以看出，假如我們能夠減少需要移動(dòng)的物品大小是非常有意義的，通過更少的拷貝動(dòng)作能夠使我們提升整個(gè)GC的處理性能。
* 托管堆之外是怎樣的情景呢？
作為負(fù)責(zé)垃圾回收的人員，有一個(gè)容易出現(xiàn)入的問題是在打掃房間時(shí)如何處理車?yán)锏臇|西，當(dāng)我們打掃衛(wèi)生時(shí)，我們需要將所有物品清理干凈。那家里的臺(tái)燈和車?yán)锏碾姵卦趺崔k？
在一些情況下，GC需要執(zhí)行代碼來清理非托管資源(如文件，數(shù)據(jù)庫連接，網(wǎng)絡(luò)連接等)，一種可能的方式是通過finalizer來進(jìn)行處理。
class?Sample
{
??????????~Sample()
??????????{
????????????????????//?FINALIZER:?CLEAN?UP?HERE
??????????}
}
在對(duì)象創(chuàng)建期間，所有帶有finalizer的對(duì)象都將被添加到一個(gè)finalizer隊(duì)列中。對(duì)象1、4、5都有finalizer，且都已在finalizer隊(duì)列當(dāng)中。讓我們來看看當(dāng)對(duì)象2和4在應(yīng)用程序中不再被引用，且系統(tǒng)正準(zhǔn)備進(jìn)行垃圾回收時(shí)會(huì)發(fā)生些什么。
[Stacking_Heaping6.gif]
對(duì)象2會(huì)像通常情況下那樣被垃圾回收器回收，但是當(dāng)我們處理對(duì)象4時(shí)，GC發(fā)現(xiàn)它存在于finalizer隊(duì)列中，那么GC就不會(huì)回收對(duì)象4的內(nèi)存空間，而是將對(duì)象4的finalizer移到一個(gè)叫做"freachable"的特殊隊(duì)列中。
[Stacking_Heaping7.gif]
有一個(gè)專門的線程來執(zhí)行freachable隊(duì)列中的項(xiàng)，對(duì)象4的finalizer一旦被該線程所處理，就將從freachable隊(duì)列中被移除，然后對(duì)象4就等待被回收。
[Stacking_Heaping8.gif]
因此對(duì)象4將存活至下一輪的垃圾回收。
由于在類中添加一個(gè)finalizer會(huì)增加GC的工作量，這種工作是十分昂貴的，而且會(huì)影響垃圾回收的性能和我們的程序。最好只在你確認(rèn)需要finalizer時(shí)才使用它。
在清理非托管資源時(shí)有一種更好的方法：在顯式地關(guān)閉連接時(shí)，使用IDisposalbe接口來代替finalizer進(jìn)行清理工作會(huì)更好些。
*?IDisposable
實(shí)現(xiàn)IDisposable接口的類需要執(zhí)行Dispose()方法來做清理工作(這個(gè)方法是IDisposable接口中唯一的簽名)。因此假如我們使用如下的帶有finalizer的ResourceUser類：
public?class?ResourceUser?
{
??????????~ResourceUser()?//?THIS?IS?A?FINALIZER
??????????{
????????????????????//?DO?CLEANUP?HERE
??????????}
}
?
我們可以使用IDisposable來以更好的方式實(shí)現(xiàn)相同的功能：
public?class?ResourceUser?:?IDisposable
{
??????????IDisposable?Members#region?IDisposable?Members
??????????public?void?Dispose()
??????????{
????????????????????//?CLEAN?UP?HERE!!!
??????????}
??????????#endregion
}
IDisposable被集成在了using塊當(dāng)中。在using()方法中聲明的對(duì)象在using塊的結(jié)尾處將調(diào)用Dispose()方法，using塊之外該對(duì)象將不再被引用，因?yàn)樗呀?jīng)被認(rèn)為是需要進(jìn)行垃圾回收的對(duì)象了。
public?static?void?DoSomething()
{
ResourceUser?rec?=?new?ResourceUser();
using?(rec)
{
????????????????//?DO?SOMETHING?
}?//?DISPOSE?CALLED?HERE
????????????//?DON'T?ACCESS?rec?HERE
}
我更喜歡將對(duì)象聲明放到using塊中，因?yàn)檫@樣可視化很強(qiáng)，而且rec對(duì)象在using塊的作用域之外將不再有效。這種模式的寫法更符合IDisposable接口的初衷，但這并不是必須的。
public?static?void?DoSomething()
{
using?(ResourceUser?rec?=?new?ResourceUser())
{
????????????????//?DO?SOMETHING
?
}?//?DISPOSE?CALLED?HERE
}
在類中使用using()塊來實(shí)現(xiàn)IDisposable接口,能夠使我們?cè)谇謇砝鴮?duì)象時(shí)不需要寫額外的代碼來強(qiáng)制GC回收我們的對(duì)象。
*?靜態(tài)方法
靜態(tài)方法屬于一種類型，而不是對(duì)象的實(shí)例，它允許創(chuàng)建能夠被類所共享的方法，且能夠達(dá)到"減肥"的效果，因?yàn)橹挥徐o態(tài)方法的指針(8?bytes)在內(nèi)存當(dāng)中移動(dòng)。靜態(tài)方法實(shí)體僅在應(yīng)用程序生命周期的早期被一次性加載，而不是在我們的類實(shí)例中生成。當(dāng)然，方法越大那么將其作為靜態(tài)就越高效。假如我們的方法很小(小于8?bytes)，那么將其作為靜態(tài)方法反而會(huì)影響性能，因?yàn)檫@時(shí)指針比它指向的方法所占的空間還大些。
接著來看看例子...
我們的類中有一個(gè)公共的方法SayHello()：
class?Dude
{
??????????private?string?_Name?=?"Don";
?
??????????public?void?SayHello()
??????????{
????????????????????Console.WriteLine(this._Name?+?"?says?Hello");
??????????}
}?
在每一個(gè)Dude類實(shí)例中SayHello()方法都會(huì)占用內(nèi)存空間。
[Stacking_Heaping9.gif]
一種更高效的方式是采用靜態(tài)方法，這樣我們只需要在內(nèi)存中放置唯一的SayHello()方法，而不論存在多少個(gè)Dude類實(shí)例。因?yàn)殪o態(tài)成員不是實(shí)例成員，我們不能使用this指針來進(jìn)行方法的引用。
class?Dude
{
??????????private?string?_Name?=?"Don";
?
??????????public?static?void?SayHello(string?pName)
??????????{
????????????????????Console.WriteLine(pName?+?"?says?Hello");
??????????}
}?
?
[Stacking_Heaping10.gif]
請(qǐng)注意我們?cè)趥鬟f變量時(shí)棧上發(fā)生了些什么(可以參看<第二部分>)。我們需要通過例子的看看是否需要使用靜態(tài)方法來提升性能。例如,一個(gè)靜態(tài)方法需要很多參數(shù)而且沒有什么復(fù)雜的邏輯，那么在使用靜態(tài)方法時(shí)我們可能會(huì)降低性能。
*?靜態(tài)變量：注意了！
對(duì)于靜態(tài)變量，有兩件事情我們需要注意。假如我們的類中有一個(gè)靜態(tài)方法用于返回一個(gè)唯一值，而下面的實(shí)現(xiàn)會(huì)造成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;
??????????}
}
假如有兩個(gè)線程同時(shí)調(diào)用GetNextNumber()方法，而且它們?cè)趕_Number的值增加前都為newNumber分配了相同的值，那么它們將返回同樣的結(jié)果!
我們需要顯示地為方法中的靜態(tài)變量鎖住讀/寫內(nèi)存的操作，以保證同一時(shí)刻只有一個(gè)線程能夠執(zhí)行它們。線程管理是一個(gè)非常大的主題，而且有很多途徑可以解決線程同步的問題。使用lock關(guān)鍵字能讓代碼塊在同一時(shí)刻僅能夠被一個(gè)線程訪問。一種好的習(xí)慣是，你應(yīng)該盡量鎖較短的代碼，因?yàn)樵诔绦驁?zhí)行l(wèi)ock?代碼塊時(shí)所有線程都要進(jìn)入等待隊(duì)列，這是非常低效的。
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;
????????????????????}
??????????}
}
?
*?靜態(tài)變量：再次注意了！
靜態(tài)變量引用需要注意的另一件事情是：記住，被"root"引用的事物是不會(huì)被GC清理掉的。我遇到過的一個(gè)最煩人的例子：
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類中是靜態(tài)的，不僅集合中的對(duì)象不會(huì)被GC釋放(它們都直接被根所引用)，而且你可能注意到了，每次執(zhí)行?GetStats()方法時(shí)都會(huì)為那個(gè)文件開放一個(gè)文件流，因?yàn)樗鼪]有被關(guān)閉所以也不會(huì)被GC釋放，這個(gè)代碼將會(huì)給系統(tǒng)造成很大的災(zāi)難。假如我們有?100000個(gè)運(yùn)動(dòng)員來參加奧林匹克，那么會(huì)由于太多不可回收的對(duì)象而難以釋放內(nèi)存。天啦，多差勁的性能呀！
*?Singleton
有一種方法可以保證一個(gè)類的實(shí)例在內(nèi)存中始終保持唯一，我們可以采用Gof中的Singleton模式。(Gof:Gang?of?Four，一部非常具有代表性的設(shè)計(jì)模式書籍的作者別稱，歸納了23種常用的設(shè)計(jì)模式)
public?class?Earth
{
??????????private?static?Earth?_instance?=?new?Earth();
??????????private?Earth()?{?}
??????????public?static?Earth?GetInstance()?{?return?_instance;?}
}
我們的Earth類有一個(gè)私有構(gòu)造器，所以Earth類能夠執(zhí)行它的構(gòu)造器來創(chuàng)建一個(gè)Earth實(shí)例。我們有一個(gè)Earth類的靜態(tài)實(shí)例，還有一個(gè)靜態(tài)方法來獲得這個(gè)實(shí)例。這種特殊的實(shí)現(xiàn)是線程安全的，因?yàn)镃LR保證了靜態(tài)變量的創(chuàng)建是線程安全的。這是我認(rèn)為在C#中實(shí)現(xiàn)singleton模式最為明智的方式。
*?.NET?Framework?2.0中的靜態(tài)類
在.NET?2.0?Framework中我們有一種靜態(tài)類，此類中的所有成員都是靜態(tài)的。這中特性對(duì)于工具類是非常有用的，而且能夠節(jié)省內(nèi)存空間，因?yàn)樵擃愔淮嬖谟趦?nèi)存中的某個(gè)地方，不能在任何情況下被實(shí)例化。
*?總結(jié)一下...
總的來說,我們能夠提升GC表現(xiàn)的方式有：
1.?清理工作。不要讓資源一直打開！盡可能地保證關(guān)閉所有打開的連接，清除所有非托管的資源。當(dāng)使用非托管對(duì)象時(shí)，初始化工作盡量完些，清理工作要盡量及時(shí)點(diǎn)。
2.?不要過度地引用。需要時(shí)才使用引用對(duì)象，記住，如果你的對(duì)象是活動(dòng)著的，所有被它引用的對(duì)象都不會(huì)被垃圾回收。當(dāng)我們想清理一些類所引用的事物，可以通過將這些引用設(shè)置為null來移除它們。我喜歡采用的一種方式是將未使用的引用指向一個(gè)輕量級(jí)的NullObject來避免產(chǎn)生null引用的異常。在GC?進(jìn)行垃圾回收時(shí)，更少的引用將減少映射處理的壓力。
3.?少使用finalizer。Finalizer在垃圾回收時(shí)是非常昂貴的資源，我們應(yīng)該只在必要時(shí)使用。如果我們使用IDisposable來代替finalizer會(huì)更高效些，因?yàn)槲覀兊膶?duì)象能夠直接被GC回收而不是在第二次回收時(shí)進(jìn)行。
4.?盡量保持對(duì)象和它們的子對(duì)象在一塊兒。GC在復(fù)制大塊內(nèi)存數(shù)據(jù)來放到一起時(shí)是很容易的，而復(fù)制堆中的碎片是很費(fèi)勁的，所以當(dāng)我們聲明一個(gè)包含許多其他對(duì)象的對(duì)象時(shí)，我們應(yīng)該在初始化時(shí)盡量讓他們?cè)谝粔K兒。
5.?最后，使用靜態(tài)方法來保持對(duì)象的輕便也是可行的。
下一次，我們將更加深入GC的處理過程，看看在你的程序執(zhí)行時(shí)GC是如何發(fā)現(xiàn)問題并清除它們的。
To?be?long?long?continued...
http://www.cnblogs.com/c2303191/articles/1065675.html
?
?
壓棧(入棧)=執(zhí)行方法中的指令 .NET中棧和堆的比較1 原文出處：http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覍⒅v解棧和堆的基本知識(shí)，變量類型以及為什么一些變量能夠按照它們自己的方式工作。
在.NET?framework環(huán)境下，當(dāng)我們的代碼執(zhí)行時(shí)，內(nèi)存中有兩個(gè)地方用來存儲(chǔ)這些代碼。假如你不曾了解，那就讓我來給你介紹棧(Stack)和堆(Heap)。棧和堆都用來幫助我們運(yùn)行代碼的，它們駐留在機(jī)器內(nèi)存中，且包含所有代碼執(zhí)行所需要的信息。
*?棧vs堆：有什么不同？
棧負(fù)責(zé)保存我們的代碼執(zhí)行（或調(diào)用）路徑,而堆則負(fù)責(zé)保存對(duì)象（或者說數(shù)據(jù)，接下來將談到很多關(guān)于堆的問題）的路徑。
可以將棧想象成一堆從頂向下堆疊的盒子。當(dāng)每調(diào)用一次方法時(shí)，我們將應(yīng)用程序中所要發(fā)生的事情記錄在棧頂?shù)囊粋€(gè)盒子中,而我們每次只能夠使用棧頂?shù)哪莻€(gè)盒子。當(dāng)我們棧頂?shù)暮凶颖皇褂猛曛?#xff0c;或者說方法執(zhí)行完畢之后，我們將拋開這個(gè)盒子然后繼續(xù)使用棧頂上的新盒子。堆的工作原理比較相似，但大多數(shù)時(shí)候堆用作保存信息而非保存執(zhí)行路徑，因此堆能夠在任意時(shí)間被訪問。與棧相比堆沒有任何訪問限制，堆就像床上的舊衣服，我們并沒有花時(shí)間去整理，那是因?yàn)榭梢噪S時(shí)找到一件我們需要的衣服，而棧就像儲(chǔ)物柜里堆疊的鞋盒，我們只能從最頂層的盒子開始取，直到發(fā)現(xiàn)那只合適的。
[heapvsstack1.gif]
以上圖片并不是內(nèi)存中真實(shí)的表現(xiàn)形式，但能夠幫助我們區(qū)分棧和堆。
棧是自行維護(hù)的，也就是說內(nèi)存自動(dòng)維護(hù)棧，當(dāng)棧頂?shù)暮凶硬辉俦皇褂?#xff0c;它將被拋出。相反的，堆需要考慮垃圾回收，垃圾回收用于保持堆的整潔性，沒有人愿意看到周圍都是贓衣服，那簡(jiǎn)直太臭了！
*?棧和堆里有些什么？
當(dāng)我們的代碼執(zhí)行的時(shí)候，棧和堆中主要放置了四種類型的數(shù)據(jù)：值類型(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.指針：
在內(nèi)存管理方案中放置的第三種類型是類型引用，引用通常就是一個(gè)指針。我們不會(huì)顯示的使用指針，它們由公共語言運(yùn)行時(shí)（CLR）來管理。指針（或引用）是不同于引用類型的，是因?yàn)楫?dāng)我們說某個(gè)事物是一個(gè)引用類型時(shí)就意味著我們是通過指針來訪問它的。指針是一塊內(nèi)存空間，而它指向另一個(gè)內(nèi)存空間。就像棧和堆一樣，指針也同樣要占用內(nèi)存空間，但它的值是一個(gè)內(nèi)存地址或者為空。
[heapvsstack2.gif]
4.指令：
在后面的文章中你會(huì)看到指令是如何工作的...
*?如何決定放哪兒?
這里有一條黃金規(guī)則:
1.?引用類型總是放在堆中。(夠簡(jiǎn)單的吧?)
2.?值類型和指針總是放在它們被聲明的地方。(這條稍微復(fù)雜點(diǎn)，需要知道棧是如何工作的，然后才能斷定是在哪兒被聲明的。)
就像我們先前提到的，棧是負(fù)責(zé)保存我們的代碼執(zhí)行(或調(diào)用)時(shí)的路徑。當(dāng)我們的代碼開始調(diào)用一個(gè)方法時(shí),將放置一段編碼指令(在方法中)到棧上,緊接著放置方法的參數(shù)，然后代碼執(zhí)行到方法中的被“壓棧”至棧頂?shù)淖兞课恢谩Ｍㄟ^以下例子很容易理解...
下面是一個(gè)方法（Method）:
???????????public?int?AddFive(int?pValue)
??????????{
????????????????int?result;
????????????????result?=?pValue?+?5;
????????????????return?result;
??????????}
現(xiàn)在就來看看在棧頂發(fā)生了些什么，記住我們所觀察的棧頂下實(shí)際已經(jīng)壓入了許多別的內(nèi)容。
首先方法（只包含需要執(zhí)行的邏輯字節(jié)，即執(zhí)行該方法的指令，而非方法體內(nèi)的數(shù)據(jù)）入棧，緊接著是方法的參數(shù)入棧。（我們將在后面討論更多的參數(shù)傳遞）
[heapvsstack3.gif]
接著，控制（即執(zhí)行方法的線程）被傳遞到堆棧中AddFive()的指令上，
[heapvsstack4.gif]
當(dāng)方法執(zhí)行時(shí)，我們需要在棧上為“result”變量分配一些內(nèi)存，
[heapvsstack5.gif]
The?method?finishes?execution?and?our?result?is?returned.
方法執(zhí)行完成，然后方法的結(jié)果被返回。
[heapvsstack6.gif]
通過將棧指針指向AddFive()方法曾使用的可用的內(nèi)存地址，所有在棧上的該方法所使用內(nèi)存都被清空，且程序?qū)⒆詣?dòng)回到棧上最初的方法調(diào)用的位置(在本例中不會(huì)看到)。
[heapvsstack7.gif]
在這個(gè)例子中，我們的"result"變量是被放置在棧上的，事實(shí)上，當(dāng)值類型數(shù)據(jù)在方法體中被聲明時(shí)，它們都是被放置在棧上的。
值類型數(shù)據(jù)有時(shí)也被放置在堆上。記住這條規(guī)則--值類型總是放在它們被聲明的地方。好的，如果一個(gè)值類型數(shù)據(jù)在方法體外被聲明，且存在于一個(gè)引用類型中，那么它將被堆中的引用類型所取代。
來看另一個(gè)例子：
假如我們有這樣一個(gè)MyInt類（它是引用類型因?yàn)樗且粋€(gè)類類型）：
??????????public?class?MyInt
??????????{?????????
?????????????public?int?MyValue;
??????????}
然后執(zhí)行下面的方法:
??????????public?MyInt?AddFive(int?pValue)
??????????{
????????????????MyInt?result?=?new?MyInt();
????????????????result.MyValue?=?pValue?+?5;
????????????????return?result;
??????????}
就像前面提到的，方法及方法的參數(shù)被放置到棧上，接下來，控制被傳遞到堆棧中AddFive()的指令上。
[heapvsstack8.gif]
接著會(huì)出現(xiàn)一些有趣的現(xiàn)象...
因?yàn)?/span>"MyInt"是一個(gè)引用類型,它將被放置在堆上,同時(shí)在棧上生成一個(gè)指向這個(gè)堆的指針引用。
[heapvsstack9.gif]
在AddFive()方法被執(zhí)行之后，我們將清空...
[heapvsstack10.gif]
我們將剩下孤獨(dú)的MyInt對(duì)象在堆中（棧中將不會(huì)存在任何指向MyInt對(duì)象的指針!）
[heapvsstack11.gif]
這就是垃圾回收器（后簡(jiǎn)稱GC）起作用的地方。當(dāng)我們的程序達(dá)到了一個(gè)特定的內(nèi)存閥值，我們需要更多的堆空間的時(shí)候，GC開始起作用。GC將停止所有正在運(yùn)行的線程，找出在堆中存在的所有不再被主程序訪問的對(duì)象，并刪除它們。然后GC會(huì)重新組織堆中所有剩下的對(duì)象來節(jié)省空間，并調(diào)整棧和堆中所有與這些對(duì)象相關(guān)的指針。你肯定會(huì)想到這個(gè)過程非常耗費(fèi)性能，所以這時(shí)你就會(huì)知道為什么我們需要如此重視棧和堆里有些什么，特別是在需要編寫高性能的代碼時(shí)。
Ok...?這太棒了,?當(dāng)它是如何影響我的？
Good?question.?
當(dāng)我們使用引用類型時(shí)，我們實(shí)際是在處理該類型的指針，而非該類型本身。當(dāng)我們使用值類型時(shí)，我們是在使用值類型本身。聽起來很迷糊吧？
同樣，例子是最好的描述。
假如我們執(zhí)行以下的方法：
??????????public?int?ReturnValue()
??????????{
????????????????int?x?=?new?int();
????????????????x?=?3;
????????????????int?y?=?new?int();
????????????????y?=?x;?????
????????????????y?=?4;?????????
????????????????return?x;
??????????}
我們將得到值3，很簡(jiǎn)單，對(duì)吧？
假如我們首先使用MyInt類
?????public?class?MyInt
??????????{
????????????????public?int?MyValue;
??????????}
接著執(zhí)行以下的方法：
??????????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怎么會(huì)變成4了呢？...??看看我們所做的然后就知道是怎么回事了：
在第一例子中，一切都像計(jì)劃的那樣進(jìn)行著：
??????????public?int?ReturnValue()
??????????{
????????????????int?x?=?3;
????????????????int?y?=?x;???
????????????????y?=?4;
????????????????return?x;
??????????}
[heapvsstack12.gif]
在第二個(gè)例子中，我們沒有得到"3"是因?yàn)樽兞?/span>"x"和"y"都同時(shí)指向了堆中相同的對(duì)象。
??????????public?int?ReturnValue2()
??????????{
????????????????MyInt?x;
????????????????x.MyValue?=?3;
????????????????MyInt?y;
????????????????y?=?x;???????????????
????????????????y.MyValue?=?4;
????????????????return?x.MyValue;
??????????}
[heapvsstack13.gif]
希望以上內(nèi)容能夠使你對(duì)C#中的值類型和引用類型的基本區(qū)別有一個(gè)更好的認(rèn)識(shí)，并且對(duì)指針及指針是何時(shí)被使用的有一定的基本了解。在系列的下一個(gè)部分，我們將深入內(nèi)存管理并專門討論方法參數(shù)。
To?be?continued...
?
?
.NET中棧和堆的比較 #2 原文出處：http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory2B01142006125918PM/csharp_memory2B.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覍⒅v解我們必須要注意的方法傳參的行為。
在第一部分里我介紹了棧和堆的基本功能，還介紹到了在程序執(zhí)行時(shí)值類型和引用類型是如何分配的，而且還談到了指針。
*?參數(shù)，大問題
這里有一個(gè)代碼執(zhí)行時(shí)的詳細(xì)介紹，我們將深入第一部分出現(xiàn)的方法調(diào)用過程...
當(dāng)我們調(diào)用一個(gè)方法時(shí)，會(huì)發(fā)生以下的事情：
1.方法執(zhí)行時(shí)，首先在棧上為對(duì)象實(shí)例中的方法分配空間，然后將方法拷貝到棧上（此時(shí)的棧被稱為幀），但是該空間中只存放了執(zhí)行方法的指令，并沒有方法內(nèi)的數(shù)據(jù)項(xiàng)。
3.方法參數(shù)的分配和拷貝是需要空間的，這一點(diǎn)是我們需要進(jìn)一步注意。
示例代碼如下:
??????????public?int?AddFive(int?pValue)
??????????{
????????????????int?result;
????????????????result?=?pValue?+?5;
????????????????return?result;
??????????}
此時(shí)棧開起來是這樣的:
[heapvsstack2-1.gif]
就像第一部分討論的那樣，放在棧上的參數(shù)是如何被處理的，需要看看它是值類型還是引用類型。值類型的值將被拷貝到棧上，而引用類型的引用（或者說指針）將被拷貝到棧上。
*?值類型傳遞
首先，當(dāng)我們傳遞一個(gè)值類型參數(shù)時(shí)，棧上被分配好一個(gè)新的空間，然后該參數(shù)的值被拷貝到此空間中。
來看下面的方法：
?????class?Class1
?????{
??????????public?void?Go()
??????????{
??????????????int?x?=?5;
?????????????
??????????????AddFive(x);
??????????????Console.WriteLine(x.ToString());
??????????}
??????????public?int?AddFive(int?pValue)
??????????{
??????????????pValue?+=?5;
??????????????return?pValue;
??????????}
?????}
方法Go()被放置到棧上，然后執(zhí)行，整型變量"x"的值"5"被放置到棧頂空間中。
[heapvsstack2-2.gif]
然后AddFive()方法被放置到棧頂上，接著方法的形參值被拷貝到棧頂，且該形參的值就是"x"的拷貝。
[heapvsstack2-3.gif]
當(dāng)AddFive()方法執(zhí)行完成之后，線程就通過預(yù)先放置的指令返回到Go()方法的地址，然后從棧頂依次將變量pValue和方法AddFive()移除掉:
[heapvsstack2-4.gif]
所以我們的代碼輸出的值是"5"，對(duì)吧？這里的關(guān)鍵之處就在于任何傳入方法的值類型參數(shù)都是復(fù)制拷貝的，所以原始變量中的值是被保留下來而沒有被改變的。
必須注意的是，如果我們要將一個(gè)非常大的值類型數(shù)據(jù)(如數(shù)據(jù)量大的struct類型)入棧，它會(huì)占用非常大的內(nèi)存空間，而且會(huì)占有過多的處理器周期來進(jìn)行拷貝復(fù)制。棧并沒有無窮無盡的空間，它就像在水龍頭下盛水的杯子，隨時(shí)可能溢出。struct是一個(gè)能夠存放大量數(shù)據(jù)的值類型成員，我們必須小心地使用。
這里有一個(gè)存放大數(shù)據(jù)類型的struct:
???????????public?struct?MyStruct
???????????{
???????????????long?a,?b,?c,?d,?e,?f,?g,?h,?i,?j,?k,?l,?m;
???????????}
來看看當(dāng)我們執(zhí)行了Go()和DoSometing()方法時(shí)會(huì)發(fā)生什么：
??????????public?void?Go()
??????????{
?????????????MyStruct?x?=?new?MyStruct();
?????????????DoSomething(x);
??????????}
???????????public?void?DoSomething(MyStruct?pValue)
??????????
???????????{
??????????
????????????????????//?DO?SOMETHING?HERE....
???????????}
[heapvsstack2-5.gif]
這將會(huì)非常的低效。想象我們要是傳遞2000次MyStruct,你就會(huì)明白程序是怎么癱瘓掉的了。
那么我們應(yīng)該如何解決這個(gè)問題？可以通過下列方式來傳遞原始值的引用：
??????????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....
???????????}
通過這種方式我們能夠提高內(nèi)存中對(duì)象分配的效率。
[heapvsstack2-6.gif]
唯一需要注意的是，在我們通過引用傳遞值類型時(shí)我們會(huì)修改該值類型的值，也就是說pValue值的改變會(huì)引起x值的改變。執(zhí)行以下代碼，我們的結(jié)果會(huì)變成"123456"，這是因?yàn)閜Value實(shí)際指向的內(nèi)存空間與ｘ變量聲明的內(nèi)存空間是一致的。
?????????
??????????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;
??????????}
*?引用類型傳遞
傳遞引用類型參數(shù)的情況類似于先前例子中通過引用來傳遞值類型的情況。
如果我們使用引用類型：
???????????public?class?MyInt
???????????{
???????????????public?int?MyValue;
???????????}
[heapvsstack2-7.gif]
然后調(diào)用Go()方法，MyInt對(duì)象將放置在堆上：
??????????public?void?Go()
??????????{
?????????????MyInt?x?=?new?MyInt();??????????????
??????????}
如果我們執(zhí)行下面的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;
???????????}
將發(fā)生這樣的事情...
[heapvsstack2-8.gif]
1.方法Go()入棧
2.Go()方法中的變量x入棧
3.方法DoSomething()入棧
4.參數(shù)pValue入棧
5.ｘ的值(MyInt對(duì)象的在棧中的指針地址)被拷貝到pValue中
因此，當(dāng)我們通過MyInt類型的pValue來改變堆中MyInt對(duì)象的MyValue成員值后，接著又使用指向該對(duì)象的另一個(gè)引用ｘ來獲取了其MyValue成員值，得到的值就變成了"12345"。
而更有趣的是，當(dāng)我們通過引用來傳遞一個(gè)引用類型時(shí)，會(huì)發(fā)生什么？
讓我們來檢驗(yàn)一下。假如我們有一個(gè)"Thing"類和兩個(gè)繼承于"Thing"的"Animal"和"Vegetable"?類：
??????????
???????????public?class?Thing
???????????{
???????????}
???????????public?class?Animal:Thing
???????????{
???????????????public?int?Weight;
???????????}
???????????public?class?Vegetable:Thing
???????????{
???????????????public?int?Length;
???????????}
然后執(zhí)行下面的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
讓我們來看看發(fā)生了什么：
[heapvsstack2-9.gif]
1.Go()方法入棧
2.x指針入棧
3.Animal對(duì)象實(shí)例化到堆中
4.Switcharoo()方法入棧
5.pValue入棧且指向ｘ
[heapvsstack2-10.gif]
6.Vegetable對(duì)象實(shí)例化到堆中
7.x的值通過被指向Vegetable對(duì)象地址的pValue值所改變。
如果我們不使用Thing的引用，相反的，我們得到結(jié)果變量x將會(huì)是Animal類型的。
如果以上代碼對(duì)你來說沒有什么意義，那么請(qǐng)繼續(xù)看看我的文章中關(guān)于引用變量的介紹，這樣能夠?qū)σ妙愋偷淖兞渴侨绾喂ぷ鞯臅?huì)有一個(gè)更好的理解。
我們看到了內(nèi)存是怎樣處理參數(shù)傳遞的，在系列的下一部分中，我們將看看棧中的引用變量發(fā)生了些什么，然后考慮當(dāng)我們拷貝對(duì)象時(shí)是如何來解決某些問題的。
To?be?continued...
?
?
.NET中棧和堆的比較 #3 原文出處http://www.c-sharpcorner.com/UploadFile/rmcochran/chsarp_memory401152006094206AM/chsarp_memory4.aspx
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覀儗⑸婕暗蕉阎幸米兞恳鸬膯栴}，以及如何使用ICloneable接口來解決該問題。
需要回顧堆棧基礎(chǔ)，值類型和引用類型，請(qǐng)轉(zhuǎn)到第一部分和第二部分
*?副本并不是真的副本
為了清楚的闡明問題，讓我們來比較一下當(dāng)堆中存在值類型和引用類型時(shí)都發(fā)生了些什么。首先來看看值類型，如下面的類和結(jié)構(gòu)。這里有一個(gè)類Dude，它的成員中有一個(gè)string型的Name字段及兩個(gè)Shoe類型的字段--RightShoe、LeftShoe，還有一個(gè)CopyDude()方法可以很容易地生成新的Dude實(shí)例。
???????????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是引用類型，而且由于結(jié)構(gòu)Shoe的兩個(gè)字段是Dude類的成員，所以它們都被放在了堆上。
[heapvsstack3-1gif]
當(dāng)我們執(zhí)行以下的方法時(shí)：
???????????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());????????????
?
???????????}
我們得到了預(yù)期的結(jié)果：
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.
如果我們將結(jié)構(gòu)Shoe換成引用類型會(huì)發(fā)生什么？問題就在于此。
假如我們將Shoe改為引用類型：
???????????public?class?Shoe{
???????????????public?string?Color;
???????????}
然后在與前面相同的Main()方法中運(yùn)行，再來看看我們的結(jié)果：
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)腳上了，很明顯出錯(cuò)了。你想知道這是為什么嗎？我們?cè)賮砜纯炊丫兔靼琢恕?br /> [heapvsstack3-2gif]
由于我們現(xiàn)在使用的Shoe是引用類型而非值類型，當(dāng)引用類型的內(nèi)容被拷貝時(shí)實(shí)際上只拷貝了該類型的指針(并沒有拷貝實(shí)際的對(duì)象)，我們需要作一些額外的工作來使我們的引用類型能夠像值類型一樣使用。
幸運(yùn)的是.NET?Framework中已經(jīng)有了一個(gè)IClonealbe接口(System.ICloneable)來幫助我們解決問題。使用這個(gè)接口可以規(guī)定所有的?Dude類必須遵守和定義引用類型應(yīng)如何被復(fù)制，以避免出現(xiàn)"共享鞋子"的問題。所有需要被克隆的類都需要使用ICloneable接口，包括Shoe?類。
System.IClonealbe只有一個(gè)方法定義：Clone()
??????????????????public?object?Clone()
??????????????????{
??????????????????}
我們應(yīng)該在Shoe類中這樣實(shí)現(xiàn)：
???????????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()中，我們創(chuàng)建了一個(gè)新的Shoe對(duì)象，克隆了所有引用類型，并拷貝了所有值類型，然后返回了這個(gè)新對(duì)象。你可能注意到了?string類已經(jīng)實(shí)現(xiàn)了ICloneable接口，所以我們可以直接調(diào)用Color.Clone()方法。因?yàn)镃lone()方法返回的是對(duì)象的引用,?所以我們需要在設(shè)置鞋的顏色前重構(gòu)這個(gè)引用。
接著，在我們的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;
????????????????}
現(xiàn)在，當(dāng)我們執(zhí)行Main()函數(shù)時(shí)：
???????????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]
在通常情況下，我們應(yīng)該"克隆"引用類型，"拷貝"值類型。(這樣，在你調(diào)試以上介紹的情況中的問題時(shí)，會(huì)減少你買來控制頭痛的阿司匹林的藥量)
在頭痛減少的激烈下，我們可以更進(jìn)一步地使用Dude類來實(shí)現(xiàn)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());????????????
???????????}
最后的結(jié)果是：
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.
非常好！
比較有意思的是請(qǐng)注意為System.String類分配的操作符("="號(hào)),它實(shí)際上是將string型對(duì)象進(jìn)行克隆，所以你不必?fù)?dān)心會(huì)發(fā)生引用拷貝。盡管如此你還是得注意一下內(nèi)存的膨脹。
如果你重新看一下前面的那些圖，會(huì)發(fā)現(xiàn)string型應(yīng)該是引用類型，所以它應(yīng)該是一個(gè)指針(這個(gè)指針指向堆中的另一個(gè)對(duì)象)，但是為了方便起見，我在圖中將string型表示為值類型(實(shí)際上應(yīng)該是一個(gè)指針)，因?yàn)橥ㄟ^"="號(hào)重新被賦值的string型對(duì)象實(shí)際上是被自動(dòng)克隆過后的。
總結(jié)一下：
通常，如果我們打算將我們的對(duì)象用于拷貝，那么我們的類應(yīng)該實(shí)現(xiàn)IClonealbe借口，這樣能夠使引用類型仿效值類型的行為。從中可以看到，搞清楚我們所使用的變量的類型是非常重要的，因?yàn)樵谥殿愋秃鸵妙愋偷膶?duì)象在內(nèi)存中的分配是有區(qū)別的。
在下一部分內(nèi)容中，會(huì)看到我們是怎樣來減少代碼在內(nèi)存中的"腳印"的，將會(huì)談到期待已久的垃圾回收器(Garbage?Collection)。
To?be?continued...
?
.NET中棧和堆的比較4 終于翻完了第四篇，本來每次都是周末發(fā)的，可惜上周末有些事兒沒忙過來，所以今天中午給補(bǔ)上來。不知道這套文章還能不能繼續(xù)了，因?yàn)樽髡咭仓粚懙搅说谒钠?#xff0c;連他都不知道第五篇什么時(shí)候出得來...原文出處
http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory_401282006141834PM/csharp_memory_4.aspx
可以參看該系列文章的前面部分內(nèi)容：Part?I，Part?II，Part?III
盡管在.NET?framework下我們并不需要擔(dān)心內(nèi)存管理和垃圾回收(Garbage?Collection)，但是我們還是應(yīng)該了解它們，以優(yōu)化我們的應(yīng)用程序。同時(shí)，還需要具備一些基礎(chǔ)的內(nèi)存管理工作機(jī)制的知識(shí)，這樣能夠有助于解釋我們?nèi)粘３绦蚓帉懼械淖兞康男袨椤Ｔ诒疚闹形覀儗⑸钊肜斫饫厥掌?#xff0c;還有如何利用靜態(tài)類成員來使我們的應(yīng)用程序更高效。
*?更小的步伐?==?更高效的分配
為了更好地理解為什么更小的足跡會(huì)更高效，這需要我們對(duì).NET的內(nèi)存分配和垃圾回收專研得更深一些。
*?圖解:
讓我們來仔細(xì)看看GC。如果我們需要負(fù)責(zé)"清除垃圾"，那么我們需要擬定一個(gè)高效的方案。很顯然，我們需要決定哪些東西是垃圾而哪些不是。
?
為了決定哪些是需要保留的，我們首先假設(shè)所有的東西都不是垃圾(墻角里堆著的舊報(bào)紙，閣樓里貯藏的廢物，壁櫥里的所有東西，等等)。假設(shè)在我們的生活當(dāng)中有兩位朋友：Joseph?Ivan?Thomas(JIT)和Cindy?Lorraine?Richmond(CLR)。Joe和Cindy知道它們?cè)谑褂檬裁?#xff0c;而且給了我們一張列表說明了我們需要需要些什么。我們將初始列表稱之為"根"列表,?因?yàn)槲覀儗⑺米髌鹗键c(diǎn)。我們需要保存一張主列表來記錄出我們家中的必備物品。任何能夠使必備物品正常工作或使用的東西也將被添加到列表中來(如果我們要看電視，那么就不能扔掉遙控器，所以遙控器將被添加到列表。如果我們要使用電腦，那么鍵盤和顯示器就得添加到列表)。
這就是GC如何保存我們的物品的，它從即時(shí)編譯器(JIT)和通用語言運(yùn)行時(shí)(CLR)中獲得"根"對(duì)象引用的列表，然后遞歸地搜索出其他對(duì)象引用來建立一張我們需要保存的物品的圖表。
根包括：
*?全局/靜態(tài)指針。為了使我們的對(duì)象不被垃圾回收掉的一種方式是將它們的引用保存在靜態(tài)變量中。
*?棧上的指針。我們不想丟掉應(yīng)用程序中需要執(zhí)行的線程里的東西。
*?CPU寄存器指針。托管堆中哪些被CPU寄存器直接指向的內(nèi)存地址上的東西必須得保留。
[Stacking_Heaping1.gif]
在以上圖片中，托管堆中的對(duì)象1、3、5都被根所引用，其中1和5時(shí)直接被引用，而3時(shí)在遞歸查找時(shí)被發(fā)現(xiàn)的。像我們之前的假設(shè)一樣，對(duì)象1是我們的電視機(jī)，對(duì)象3是我們的遙控器。在所有對(duì)象被遞歸查找出來之后我們將進(jìn)入下一步--壓縮。
*?壓縮
我們現(xiàn)在已經(jīng)繪制出哪些是我們需要保留的對(duì)象，那么我們就能夠通過移動(dòng)"保留對(duì)象"來對(duì)托管堆進(jìn)行整理。
[Stacking_Heaping2.gif]
幸運(yùn)的是，在我們的房間里沒有必要為了放入別的東西而去清理空間。因?yàn)閷?duì)象2已經(jīng)不再需要了，所以GC會(huì)將對(duì)象3移下來，同時(shí)修復(fù)它指向?qū)ο?的指針。
[Stacking_Heaping3.gif]
然后，GC將對(duì)象5也向下移,
[Stacking_Heaping4.gif]
現(xiàn)在所有的東西都被清理干凈了，我們只需要寫一張便簽貼到壓縮后的堆上，讓Claire(指CLR)知道在哪兒放入新的對(duì)象就行了。
[Stacking_Heaping5.gif]
理解GC的本質(zhì)會(huì)讓我們明白對(duì)象的移動(dòng)是非常費(fèi)力的。可以看出，假如我們能夠減少需要移動(dòng)的物品大小是非常有意義的，通過更少的拷貝動(dòng)作能夠使我們提升整個(gè)GC的處理性能。
* 托管堆之外是怎樣的情景呢？
作為負(fù)責(zé)垃圾回收的人員，有一個(gè)容易出現(xiàn)入的問題是在打掃房間時(shí)如何處理車?yán)锏臇|西，當(dāng)我們打掃衛(wèi)生時(shí)，我們需要將所有物品清理干凈。那家里的臺(tái)燈和車?yán)锏碾姵卦趺崔k？
在一些情況下，GC需要執(zhí)行代碼來清理非托管資源(如文件，數(shù)據(jù)庫連接，網(wǎng)絡(luò)連接等)，一種可能的方式是通過finalizer來進(jìn)行處理。
class?Sample
{
??????????~Sample()
??????????{
????????????????????//?FINALIZER:?CLEAN?UP?HERE
??????????}
}
在對(duì)象創(chuàng)建期間，所有帶有finalizer的對(duì)象都將被添加到一個(gè)finalizer隊(duì)列中。對(duì)象1、4、5都有finalizer，且都已在finalizer隊(duì)列當(dāng)中。讓我們來看看當(dāng)對(duì)象2和4在應(yīng)用程序中不再被引用，且系統(tǒng)正準(zhǔn)備進(jìn)行垃圾回收時(shí)會(huì)發(fā)生些什么。
[Stacking_Heaping6.gif]
對(duì)象2會(huì)像通常情況下那樣被垃圾回收器回收，但是當(dāng)我們處理對(duì)象4時(shí)，GC發(fā)現(xiàn)它存在于finalizer隊(duì)列中，那么GC就不會(huì)回收對(duì)象4的內(nèi)存空間，而是將對(duì)象4的finalizer移到一個(gè)叫做"freachable"的特殊隊(duì)列中。
[Stacking_Heaping7.gif]
有一個(gè)專門的線程來執(zhí)行freachable隊(duì)列中的項(xiàng)，對(duì)象4的finalizer一旦被該線程所處理，就將從freachable隊(duì)列中被移除，然后對(duì)象4就等待被回收。
[Stacking_Heaping8.gif]
因此對(duì)象4將存活至下一輪的垃圾回收。
由于在類中添加一個(gè)finalizer會(huì)增加GC的工作量，這種工作是十分昂貴的，而且會(huì)影響垃圾回收的性能和我們的程序。最好只在你確認(rèn)需要finalizer時(shí)才使用它。
在清理非托管資源時(shí)有一種更好的方法：在顯式地關(guān)閉連接時(shí)，使用IDisposalbe接口來代替finalizer進(jìn)行清理工作會(huì)更好些。
*?IDisposable
實(shí)現(xiàn)IDisposable接口的類需要執(zhí)行Dispose()方法來做清理工作(這個(gè)方法是IDisposable接口中唯一的簽名)。因此假如我們使用如下的帶有finalizer的ResourceUser類：
public?class?ResourceUser?
{
??????????~ResourceUser()?//?THIS?IS?A?FINALIZER
??????????{
????????????????????//?DO?CLEANUP?HERE
??????????}
}
?
我們可以使用IDisposable來以更好的方式實(shí)現(xiàn)相同的功能：
public?class?ResourceUser?:?IDisposable
{
??????????IDisposable?Members#region?IDisposable?Members
??????????public?void?Dispose()
??????????{
????????????????????//?CLEAN?UP?HERE!!!
??????????}
??????????#endregion
}
IDisposable被集成在了using塊當(dāng)中。在using()方法中聲明的對(duì)象在using塊的結(jié)尾處將調(diào)用Dispose()方法，using塊之外該對(duì)象將不再被引用，因?yàn)樗呀?jīng)被認(rèn)為是需要進(jìn)行垃圾回收的對(duì)象了。
public?static?void?DoSomething()
{
ResourceUser?rec?=?new?ResourceUser();
using?(rec)
{
????????????????//?DO?SOMETHING?
}?//?DISPOSE?CALLED?HERE
????????????//?DON'T?ACCESS?rec?HERE
}
我更喜歡將對(duì)象聲明放到using塊中，因?yàn)檫@樣可視化很強(qiáng)，而且rec對(duì)象在using塊的作用域之外將不再有效。這種模式的寫法更符合IDisposable接口的初衷，但這并不是必須的。
public?static?void?DoSomething()
{
using?(ResourceUser?rec?=?new?ResourceUser())
{
????????????????//?DO?SOMETHING
?
}?//?DISPOSE?CALLED?HERE
}
在類中使用using()塊來實(shí)現(xiàn)IDisposable接口,能夠使我們?cè)谇謇砝鴮?duì)象時(shí)不需要寫額外的代碼來強(qiáng)制GC回收我們的對(duì)象。
*?靜態(tài)方法
靜態(tài)方法屬于一種類型，而不是對(duì)象的實(shí)例，它允許創(chuàng)建能夠被類所共享的方法，且能夠達(dá)到"減肥"的效果，因?yàn)橹挥徐o態(tài)方法的指針(8?bytes)在內(nèi)存當(dāng)中移動(dòng)。靜態(tài)方法實(shí)體僅在應(yīng)用程序生命周期的早期被一次性加載，而不是在我們的類實(shí)例中生成。當(dāng)然，方法越大那么將其作為靜態(tài)就越高效。假如我們的方法很小(小于8?bytes)，那么將其作為靜態(tài)方法反而會(huì)影響性能，因?yàn)檫@時(shí)指針比它指向的方法所占的空間還大些。
接著來看看例子...
我們的類中有一個(gè)公共的方法SayHello()：
class?Dude
{
??????????private?string?_Name?=?"Don";
?
??????????public?void?SayHello()
??????????{
????????????????????Console.WriteLine(this._Name?+?"?says?Hello");
??????????}
}?
在每一個(gè)Dude類實(shí)例中SayHello()方法都會(huì)占用內(nèi)存空間。
[Stacking_Heaping9.gif]
一種更高效的方式是采用靜態(tài)方法，這樣我們只需要在內(nèi)存中放置唯一的SayHello()方法，而不論存在多少個(gè)Dude類實(shí)例。因?yàn)殪o態(tài)成員不是實(shí)例成員，我們不能使用this指針來進(jìn)行方法的引用。
class?Dude
{
??????????private?string?_Name?=?"Don";
?
??????????public?static?void?SayHello(string?pName)
??????????{
????????????????????Console.WriteLine(pName?+?"?says?Hello");
??????????}
}?
?
[Stacking_Heaping10.gif]
請(qǐng)注意我們?cè)趥鬟f變量時(shí)棧上發(fā)生了些什么(可以參看<第二部分>)。我們需要通過例子的看看是否需要使用靜態(tài)方法來提升性能。例如,一個(gè)靜態(tài)方法需要很多參數(shù)而且沒有什么復(fù)雜的邏輯，那么在使用靜態(tài)方法時(shí)我們可能會(huì)降低性能。
*?靜態(tài)變量：注意了！
對(duì)于靜態(tài)變量，有兩件事情我們需要注意。假如我們的類中有一個(gè)靜態(tài)方法用于返回一個(gè)唯一值，而下面的實(shí)現(xiàn)會(huì)造成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;
??????????}
}
假如有兩個(gè)線程同時(shí)調(diào)用GetNextNumber()方法，而且它們?cè)趕_Number的值增加前都為newNumber分配了相同的值，那么它們將返回同樣的結(jié)果!
我們需要顯示地為方法中的靜態(tài)變量鎖住讀/寫內(nèi)存的操作，以保證同一時(shí)刻只有一個(gè)線程能夠執(zhí)行它們。線程管理是一個(gè)非常大的主題，而且有很多途徑可以解決線程同步的問題。使用lock關(guān)鍵字能讓代碼塊在同一時(shí)刻僅能夠被一個(gè)線程訪問。一種好的習(xí)慣是，你應(yīng)該盡量鎖較短的代碼，因?yàn)樵诔绦驁?zhí)行l(wèi)ock?代碼塊時(shí)所有線程都要進(jìn)入等待隊(duì)列，這是非常低效的。
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;
????????????????????}
??????????}
}
?
*?靜態(tài)變量：再次注意了！
靜態(tài)變量引用需要注意的另一件事情是：記住，被"root"引用的事物是不會(huì)被GC清理掉的。我遇到過的一個(gè)最煩人的例子：
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類中是靜態(tài)的，不僅集合中的對(duì)象不會(huì)被GC釋放(它們都直接被根所引用)，而且你可能注意到了，每次執(zhí)行?GetStats()方法時(shí)都會(huì)為那個(gè)文件開放一個(gè)文件流，因?yàn)樗鼪]有被關(guān)閉所以也不會(huì)被GC釋放，這個(gè)代碼將會(huì)給系統(tǒng)造成很大的災(zāi)難。假如我們有?100000個(gè)運(yùn)動(dòng)員來參加奧林匹克，那么會(huì)由于太多不可回收的對(duì)象而難以釋放內(nèi)存。天啦，多差勁的性能呀！
*?Singleton
有一種方法可以保證一個(gè)類的實(shí)例在內(nèi)存中始終保持唯一，我們可以采用Gof中的Singleton模式。(Gof:Gang?of?Four，一部非常具有代表性的設(shè)計(jì)模式書籍的作者別稱，歸納了23種常用的設(shè)計(jì)模式)
public?class?Earth
{
??????????private?static?Earth?_instance?=?new?Earth();
??????????private?Earth()?{?}
??????????public?static?Earth?GetInstance()?{?return?_instance;?}
}
我們的Earth類有一個(gè)私有構(gòu)造器，所以Earth類能夠執(zhí)行它的構(gòu)造器來創(chuàng)建一個(gè)Earth實(shí)例。我們有一個(gè)Earth類的靜態(tài)實(shí)例，還有一個(gè)靜態(tài)方法來獲得這個(gè)實(shí)例。這種特殊的實(shí)現(xiàn)是線程安全的，因?yàn)镃LR保證了靜態(tài)變量的創(chuàng)建是線程安全的。這是我認(rèn)為在C#中實(shí)現(xiàn)singleton模式最為明智的方式。
*?.NET?Framework?2.0中的靜態(tài)類
在.NET?2.0?Framework中我們有一種靜態(tài)類，此類中的所有成員都是靜態(tài)的。這中特性對(duì)于工具類是非常有用的，而且能夠節(jié)省內(nèi)存空間，因?yàn)樵擃愔淮嬖谟趦?nèi)存中的某個(gè)地方，不能在任何情況下被實(shí)例化。
*?總結(jié)一下...
總的來說,我們能夠提升GC表現(xiàn)的方式有：
1.?清理工作。不要讓資源一直打開！盡可能地保證關(guān)閉所有打開的連接，清除所有非托管的資源。當(dāng)使用非托管對(duì)象時(shí)，初始化工作盡量完些，清理工作要盡量及時(shí)點(diǎn)。
2.?不要過度地引用。需要時(shí)才使用引用對(duì)象，記住，如果你的對(duì)象是活動(dòng)著的，所有被它引用的對(duì)象都不會(huì)被垃圾回收。當(dāng)我們想清理一些類所引用的事物，可以通過將這些引用設(shè)置為null來移除它們。我喜歡采用的一種方式是將未使用的引用指向一個(gè)輕量級(jí)的NullObject來避免產(chǎn)生null引用的異常。在GC?進(jìn)行垃圾回收時(shí)，更少的引用將減少映射處理的壓力。
3.?少使用finalizer。Finalizer在垃圾回收時(shí)是非常昂貴的資源，我們應(yīng)該只在必要時(shí)使用。如果我們使用IDisposable來代替finalizer會(huì)更高效些，因?yàn)槲覀兊膶?duì)象能夠直接被GC回收而不是在第二次回收時(shí)進(jìn)行。
4.?盡量保持對(duì)象和它們的子對(duì)象在一塊兒。GC在復(fù)制大塊內(nèi)存數(shù)據(jù)來放到一起時(shí)是很容易的，而復(fù)制堆中的碎片是很費(fèi)勁的，所以當(dāng)我們聲明一個(gè)包含許多其他對(duì)象的對(duì)象時(shí)，我們應(yīng)該在初始化時(shí)盡量讓他們?cè)谝粔K兒。
5.?最后，使用靜態(tài)方法來保持對(duì)象的輕便也是可行的。
下一次，我們將更加深入GC的處理過程，看看在你的程序執(zhí)行時(shí)GC是如何發(fā)現(xiàn)問題并清除它們的。
To?be?long?long?continued...
?
總結(jié)
以上是生活随笔為你收集整理的.NET中栈和堆的比较【转自：c#开发园地】的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： apache ，php，mysql的安装
- 下一篇： 《大话设计模式》读书笔记-索引