系列文章導航：

.NET Discovery 系列之一--string從入門到精通(上)

.NET Discovery 系列之二--string從入門到精通(勘誤版下)

.NET Discovery 系列之三--深入理解.NET垃圾收集機制(上)

.NET Discovery 系列之四--深入理解.NET垃圾收集機制(下)

.NET Discovery 系列之五--Me JIT(上)

.NET Discovery 系列之六--Me JIT(下)

.NET Discovery 系列之七--深入理解.NET垃圾收集機制(拾貝篇)

　　關于.NET垃圾收集器(Garbage Collection)，Aicken已經在“.NET Discovery 系列”文章中有2篇的涉及，這一篇文章是對上2篇文章的補充，關于“.NET Discovery 系列”文章索引請見本文結尾。

　　第一節.垃圾回收算法與完整收集(Full GC)

　　垃圾收集器就是跟蹤所有被引用到的對象，整理對象不再被引用的對象，回收相應的內存，它使用“標記與清除”算法，分兩步回收對象:

　　Step 1.Mark-Sweep ：從應用程序的root出發，利用相互引用關系，遍歷其在Heap上動態分配的所有對象，指明需要回收的對象，標記出那些存活的對象，予以標記。

　　Step 2.Compact： 對內存中存活的對象進行移動，修改它們的指針，使之在內存中連續，這樣空閑的內存也就連續了，即完成了內存釋放工作，也解決了內存碎片問題，這個過程也可以成為指針的壓縮。

　　垃圾收集器一般將托管堆中的對象分為3代，這可以通過調用GC.MaxGeneration得知，對象按照存在時間長短進行分代，最短的分在第0代，最長的分在第2代，第2代中的對象往往是比較大的，第二代空間被稱作Large Object Heap，對于2代對象的回收，與第0、1代回收方式相比最大的不同在于，沒有了指針移動的壓縮過程。

圖1 對象的回收

　　如上圖所示，左邊的區域為第一次GC時的結構，需要注意的是GC標記的是那些存活的對象，而不是需要回收的，所以第一次回收，對象B、D沒有被標記，所以被回收了，之后GC移動了對象內存指針，使空間連續。

　　接下來看中間的部分，第二次GC開始了，C對象沒有被標記，所以被回收了，接下來A、D、F三個對象被壓縮，形成連續的內存空間，并且形成了第1、2、3代區域。

　　接下來看最右邊的部分，D對象沒有被標記，由于D對象處于第2代中，所以回收D對象后，GC沒有啟動壓縮步驟，因為對于大對象的指針移動，資源耗費成本很高。

　　對于第2代的GC稱為Full GC，新分配的對象在第0代(0代空間最大長度通常為256K)，按地址順序分配，它們通常是一些局部變量；第1代(1代空間最大長度通常為2 MB)是經過0代垃圾收集后仍然駐留在內存中的對象，它們通常是一些如表單，按鈕等對象；第2代是經歷過幾次垃圾收集后仍然駐留在內存中的對象，它們通常是一些應用程序對象。

　　可見一次Full GC需要的資源是最多的，可能是幾秒或十幾秒。

　　托管堆的內存分配以段(Segment)為單位，CLR啟動時通常為GC Heap創建2個段，分別用來存儲第0、1代對象和第2代對象，以下是通過Windbg工具查看到的GC Heap情況：

圖2 WinDbg 查看GC Heap情況

　　可以看出，GC堆被分成了兩個段，三代，每代起始地址十進制差值為12。

　　在理解方面需要注意的是，GC回收的是程序中的引用類型，值類型是保存在堆棧之中，當值類型對象出了作用域后會自動釋放內存----即彈棧，不需要垃圾收集器管理。

　　第二節.GC的工作模式

　　GC的工作模式分3種，Workstation GC with Concurrent GC off、 Workstation GC with Concurrent GC on、Server GC ，在.NET 2.0以上版本可以通過修改Config文件來改變GC工作模式，例如啟用Server GC：

<configuration> 
<runtime> 
   <gcServer enabled="true" /> 
</runtime> 
</configuration>        

        

        
        
      
        
NET技術：.NET Discovery 系列之七--深入理解.NET垃圾收集機制(拾貝篇)，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。