第一節.垃圾回收算法與完整收集(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配置工具，查看“我的電腦”節點屬性可以方便的改變GC工作模式，如下圖：
圖3 GC工作模式
Workstation GC without Concurrent: 用於單CPU的服務器，策略引擎會調節GC工作頻率，使用掛起->查找與標記->壓縮->恢復的流程進行GC工作。
Workstation GC with Concurrent: Concurrent GC與Non Concurrent GC模式相比，有著更敏捷的反應速度，Winform應用程序和Windows services 服務程序默認采用這種模式，單CPU機器上只能使用workstation GC方式，默認為 Workstation GC with Concurrent。
在這種模式下，第0、1代的收集仍然是要暫時掛起應用程序的，只有在收集第2代時，才會並行處理，這種並行收集是利用多CPU
對Full GC進行並行處理，具體原理是將Full GC過程切分成多個短暫子過程對線程進行凍結，在線程凍結時間之外，應用程序仍然可
以正常運行。這主要通過將0代空間設置的很大，使Full GC時，CLR仍然能夠在0代中進行內存分配，如果Full GC時0代內存也已用盡，那麼應用程序將被掛起，等待Full GC的完成。
Server GC: 用於多CPU的服務器，這種GC模式有著很高的性能和效率。這種模式下，CLR為每個CPU創建一個專用的GC線程，每個CPU可以獨立的為相應的 heap執行GC操作，這些GC線程是以非並發的形式工作的，收集工作與線程正常工作不能同時進行，這就是說第0、1、2代的收集都會掛起應用線程。
在.Net 4.0中，有一種新的垃圾收集機制，叫做後台收集。這種機制以concurrent GC為基礎的，如上文所講，Workstation GC with Concurrent模式中，在Full GC過程時，CLR仍然能夠在0代中進行內存分配，如果Full GC時0代內存也已用盡，那麼應用程序將被掛起，等待Full GC的完成。
這個過程在後台收集機制中是這樣工作的，在進行Full GC時可以同時進行第0、1代收集，並且後台收集是一個獨立線程完成的，這個進程任務優先級低於第0、1代收集，如果在後台收集中需要對第0、1代收集，後台收集將會等待第0、1代收集完成後再進行工作，當然第0、1代收集是需要短暫掛起應用的。
後台收集還會根據策略引擎的指示，動態調節第0、1代的容量，減少前台收集(第0、1代收集)次數。
第三節 .Net 4.0中的垃圾收集器
在.Net 3.5 SP1中，FrameWork中新增了如下方法，並且在4.0中進行了優化，GC.RegisterForFullGCNotification 、GC.WaitForFullGCApproach 、GC.WaitForFullGCComplete 、GC.CancelFullGCNotification，這幾個方法都是針對Full GC（完整收集）的。
1.GC.RegisterForFullGCNotification：這個方法將返回一個將要Full GC的信號通知，該方法有2個參數：
int maxGenerationThreshold int largeObjectHeapThreshold
這兩個參數的含義是指的是第2代中存活的對象個數和大對象堆中對象個數，滿足這兩個參數後，便會引發通知,由此看來LOH也許並不是第2代，.Net GC也許也並不只是3代，
這一點在.Net Discovery 系列之三--深入理解.Net垃圾收集機制(上)中已有描述。
2.GC.CancelFullGCNotification：取消已經注冊的垃圾收集通知
這兩個方法調用示例：
代碼
// Variable for continual checking in the
// While loop in the WaitForFullGCProc method.
static bool checkForNotify = false;
// Variable for suspending work
// (such servicing allocated server requests)
// after a notification is received and then
// resuming allocation after inducing a garbage collection.
static bool bAllocate = false;
// Variable for ending the example.
static bool finalExit = false;
// Collection for objects that
// simulate the server request workload.
static List<byte[]> load = new List<byte[]>();
public static void Main(string[] args)
{
try
{
// Register for a notification.
GC.RegisterForFullGCNotification(10, 10);
Console.WriteLine("Registered for GC notification.");
checkForNotify = true;
bAllocate = true;
// Start a thread using WaitForFullGCProc.
Thread thWaitForFullGC = new Thread(new ThreadStart(WaitForFullGCProc));
thWaitForFullGC.Start();
// While the thread is checking for notifications in
// WaitForFullGCProc, create objects to simulate a server workload.
try
{
int lastCollCount = 0;
int newCollCount = 0;
while (true)
{
if (bAllocate)
{
load.Add(new byte[1000]);
newCollCount = GC.CollectionCount(2);
if (newCollCount != lastCollCount)
{
// Show collection count when it increases:
Console.WriteLine("Gen 2 collection count: {0}", GC.CollectionCount(2).ToString());
lastCollCount = newCollCount;
}
// For ending the example (arbitrary).
if (newCollCount == 500)
{
finalExit = true;
checkForNotify = false;
break;
}
}
}
}
catch (OutOfMemoryException)
{
Console.WriteLine("Out of memory.");
}
finalExit = true;
checkForNotify = false;
GC.CancelFullGCNotification();
}
catch (InvalidOperationException invalidOp)
{
Console.WriteLine("GC Notifications are not supported while concurrent GC is enabled.\n"
+ invalidOp.Message);
}
}
3.GC.WaitForFullGCApproach：用來獲得垃圾收集器是否將要啟動完整垃圾收集的工作，該方法返回GCNotificationStatus枚舉值，當枚舉為Succeeded時，
你應當做一些工作，例如阻止手動調用GC.Collect()方法，以免浪費資源。
該方法應與GC.WaitForFullGCComplete()同時使用，以確定CLR執行了完整垃圾收集。
代碼
// 查看是否將啟動完整收集
GCNotificationStatus s = GC.WaitForFullGCApproach();
if (s == GCNotificationStatus.Succeeded)
{
//do not GC.Collect()
}
else if (s == GCNotificationStatus.Canceled)
{
// GC.Collect()
}
4.GC.WaitForFullGCComplete：
用來獲得垃圾收集器是否已經完成完整垃圾收集：
代碼
GCNotificationStatus s = GC.WaitForFullGCApproach ();
s = GC.WaitForFullGCComplete ();
if (s == GCNotificationStatus.Succeeded) //已經完成了Full GC
{
//do not GC.Collect()
}
else if(s == GCNotificationStatus.Canceled)
{
// GC.Collect()
}
我是緣清(aicken)，請您繼續關注我的下一篇文章。
