.Net 垃圾回收與大物件處理

英文原文：Maoni Stephens，編譯：趙玉開（@玉開Sir）

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和obj3obj1和obj33 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://www.php.cn/

 以上就是.Net 垃圾回收與大對象處理的內容，更多相關內容請關注PHP中文網（www.php. cn）！