本文引自:http://www.cnblogs.com/yukaizhao/archive/2011/11/21/dot_net_gc_large_object_heap.html
CLR垃圾回收器根據所占空間大小劃分對象。大對象和小對象的處理方式有很大區別。比如內存碎片整理 ------ 在內存中移動大對象的成本是昂貴的，讓我們研究一下垃圾回收器是如何處理大對象的，大對象對程序性能有哪些潛在的影響。
大對象堆和垃圾回收
在.Net 1.0和2.0中，如果一個對象的大小超過85000byte，就認為這是一個大對象。這個數字是根據性能優化的經驗得到的。當一個對象申請內存大小達到這個閥值，它就會被分配到大對象堆上。這意味著什麼呢？要理解這個，我們需要理解.Net垃圾回收機制。
如大多人所知道的，.Net GC是按照“代”來回收的。程序中的對象共有3代，0代、1代和2代，0代是最年輕的對象，2代對象存活的時間最長。GC按代回收垃圾也是出於性能考慮的；通常的對象都會在0代是被回收。例如，在一個asp.net程序中，和每一個請求相關的對象都應該在請求結束時回收掉。而沒有被回收的對象會成為1代對象；也就是說1代對象是常駐內存對象和馬上消亡對象之間的一個緩沖區。
從代的角度看，大對象屬於2代對象，因為只有在2代回收時才會處理大對象。當某代垃圾回收執行時，會同時執行更年輕代的垃圾回收。比如：當1代垃圾回收時會同時回收1代和0代的對象，當2代垃圾回收時會執行1代和0代的回收.
代是垃圾回收器區分內存區域的邏輯視圖。從物理存儲角度看，對象分配在不同的托管堆上。一個托管堆（managed heap）是垃圾回收器從操作系統申請的內存區（通過調用windows api VirtualAlloc）。當CLR載入內存之後，會初始化兩個托管堆，一個大對象堆（LOH –large object heap）和一個小對象對（SOH – small object heap）。
內存分配請求就是將托管對象放到對應的托管堆上。如果對象的大小小於85000byte，它會被放置在SOH；否則會被放在LOH上。
對於SOH，對象在執行一次垃圾回收之後，會進入到下一代。也就是說如果在第一次執行垃圾回收時，存活下來的對象會進入第二代，如果在第2次垃圾回收之後該對象仍然沒有被當作垃圾回收掉，它就會成為2代對象；2代對象就是最老的對象不會在提升代數。
當觸發垃圾回收時，垃圾回收器會在小對象堆做碎片整理，將存活下來的對象移動到一起。而對於大對象堆，由於移動內存的開銷很大，CLR團隊選擇只是清除它們，將回收掉的對象組成一個列表，以便滿足下次有大對象申請使用內存，相鄰的垃圾對象會被合並成一塊空閒的內存塊。
需要時時留意的是，直到.Net 4.0中也不會對大對象堆做碎片整理操作，將來也許會做。因此如果你要分配大對象並不想他們被移動，你可以使用fixed語句。
如下小對象堆SOH的回收示意圖
上圖中第一次垃圾回收之前有四個對象obj0-3；在第一垃圾回收之後obj1和obj3被回收了，同時obj2和obj0移動到一起了；在第二次垃圾回收之前有分配了三個對象obj4-6；在第二次執行垃圾回收之後obj2和obj5被回收了，obj4和obj6被移動到obj0旁邊。
下圖是大對象堆LOH回收示意圖
可以看到在未執行垃圾回收之前，一共有四個對象obj0-3；第一次二代垃圾回收之後obj1和obj2被回收掉了，回收掉之後obj1和obj2所占空間被合並到了一起，在obj4申請分配內存時就把obj1和obj2回收後釋放的空間分配給它了；同時留下了一塊內存碎片。如果這個碎片的大小小於85000byte，那麼這個碎片就在這個程序的生命周期中永遠不能被再次利用了。
如果大對象堆上沒有足夠的空閒內存容納要申請的大對象空間，CLR首先會嘗試向操作系統申請內存，如果申請失敗，就會觸發一次二代回收來嘗試釋放一些內存。
在2代垃圾回收時，可以將不需要的內存通過VirtualFree交還給操作系統。交還的過程參見下圖：
什麼時候回收大對象呢？
在討論什麼時候回收大對象之前先來看下普通的垃圾回收操作什麼時機執行吧。垃圾回收在下列情況下發生：
1. 申請的空間超過0代內存大小或者大對象堆的閥值，多數的托管堆垃圾回收在這種情況下發生
2. 在程序代碼中調用GC.Collect方法時；如果在調用GC.Collect方法是傳入GC.MaxGeneration參數時，會執行所有代對象的垃圾回收，包括大對象堆的垃圾回收
3. 操作系統內存不足時，當應用程序收到操作系統發出的高內存通知時
4. 如果垃圾回收算法認為做二代回收是有收效時會觸發二代垃圾回收
5. 每一代對象堆的都有一個所占空間大小閥值的屬性，當你分配對象到某一代，你增長了內存總量接近了該代的閥值，或者分配對象導致這一代的堆大小超過了堆閥值，就會發生一次垃圾回收。因此當你分配小對象或者大對象時，會對應消耗0代堆或者大對象堆的閥值。當垃圾回收器將對象代數提升到1代或者2代時，會消耗1、2代的閥值。在程序運行中這些閥值是動態變化的。
大對象堆性能影響
讓我們先看下分配大對象的代價。 CLR為每個新對象分配內存時都要保證這些內存清空的，是沒有被其他對象使用的（I give out is cleared）。這就意味著分配的代價完全被清理（clearing）的代價控制著（除非在分配時觸發了一次垃圾回收）。如果清空1byte需要2個周期（cycles），就意味著清除一個最小的大對象需要170,000個周期。通常情況下人們不會分配超大的對象，比如說在2GHz的機器上分配16M大小的對象，大約需要16ms來清空內存。這代價太大了。
讓我們在看下回收的代價。前面提到過，大對象和2代齡對象一起回收。如果大對象或者2代對象占用空間超過其閥值時，就會觸發2代對象的回收。如果2代回收因為大對象堆超過閥值被觸發，2代對象堆本身沒有多少對象可以做回收。如果在2代堆上沒有多少對象，這問題不大。但是如果2代堆很大對象很多，過多的2代回收就會導致性能問題。如果是臨時性的分配大對象，就需要很多的時間來運行垃圾回收；也就是說如果你持續的使用大對象然後又釋放大對象對性能會有很大的負面影響。
大對象堆上的巨大對象通常是數組（很少有一個對象很大的情況）。如果對象中的元素是強引用，代價會很高；如果元素之間沒有相互引用，垃圾回收時就不需要遍歷整個數組。例如：用一個數組來保存二叉樹的節點，一種方法是在節點中強引用左右節點：
class Node { Data d; Node left; Node right; } Node[] binaryTree = new Node[num_nodes]; 如果num_nodes是一個很大的數字，就意味著每個節點都至少需要查看二個引用元素。一種替代方案是在節點中保存左右節點元素的數組索引號
class Node { Data d; uint left_index; uint right_index; } 這樣的話，元素之間的引用關系去掉了；可以通過binaryTree[left_index]來獲得引用的節點。垃圾回收器在做垃圾回收時也不需要看相關的引用元素了。
為大對象堆收集性能數據
有幾種方法可以收集大對象堆相關的性能數據。在我解釋這些方法之前，讓我們先談一下為什麼需要收集大對象堆相關的性能數據。
在你開始上搜集某個方面的性能數據時，有可能你已經找到這方面造成性能瓶頸的證據；或者你已經沒有找遍了所有方面都沒有發現問題。
在查找性能問題時.Net CLR Memory 性能計數器通常是應該先考慮使用的工具。和LOH相關的計數器有generation 2 collectioins（2代堆收集次數）和large object heap size大對象堆大小。Generation 2 collections顯示的是進程啟動之後2代垃圾回收操作發生的次數。Large object heap size計數器顯示的是當前大對象堆的大小值，包括空閒空間；這個計數器是在每次垃圾回收操作之後做更新，並非每次分配內存都做更新。
可以參考下圖在windows性能計數器中觀察.Net CLR Memory相關性能數據
你也可以通過程序查詢這些計數器的值；很多人通過程序的方式收集性能計數器來幫助查找性能瓶頸。
當然也可以使用調試器winddbg觀察大對象堆。
最後提示一下：到目前為止，大對象堆作為垃圾回收的一部分是不做內存碎片整理的，但是這個只是一個clr的實現細節，程序代碼不應該依賴這個特點。如果要確保對象不會被垃圾回收器移動，就要使用fixed語句。
原文出處： http://msdn.microsoft.com/en-us/magazine/cc534993.aspx
