.NET中的記憶體管理，GC機制，記憶體釋放過程

引言

作為一個.NET程式員，我們知道托管代碼的記憶體管理是自動的。.NET可以保證我們的托管程式在結束時全部釋放，這為我們程式設計人員省去了不少麻煩，我們可以連想都不想怎麼去管理記憶體，反正.NET自己會保證一切。好吧，有道理，有一定的道理。問題是，當我們用到非托管資源時.NET就不能自動管理了。這是因為非托管代碼不受CLR（Common Language Runtime）控制，超出CLR的管理範圍。那麼如何處理這些非托管資源呢，.NET又是如何管理并釋放托管資源的呢？

--------------------------------------------------------------------------------

自動記憶體管理和GC

在原始程式中堆的記憶體配置設定是這樣的：找到第一個有足夠空間的記憶體位址（沒被占用的），然後将該記憶體配置設定。當程式不再需要此記憶體中的資訊時程式員需要手動将此記憶體釋放。堆的記憶體是公用的，也就是說所有程序都有可能覆寫另一程序的記憶體内容，這就是為什麼很多設計不當的程式甚至會讓作業系統本身都down掉。我們有時碰到的程式莫名其妙的死掉了（随機現象），也是因為記憶體管理不當引起的（可能由于本身程式的記憶體問題或是外來程式造成的）。另一個常見的執行個體就是大家經常看到的遊戲的Trainer，他們通過直接修改遊戲的記憶體達到"無敵"的效果。明白了這些我們可以想象如果記憶體位址被用混亂了的話會多麼危險，我們也可以想象為什麼C++程式員（某些）一提起指針就頭疼的原因了。另外，如果程式中的記憶體不被程式員手動釋放的話那麼這個記憶體就不會被重新配置設定，直到電腦重起為止，也就是我們所說的記憶體洩漏。所說的這些是在非托管代碼中，CLR通過AppDomain實作代碼間的隔離避免了這些記憶體管理問題，也就是說一個AppDomain在一般情況下不能讀/寫另一AppDomain的記憶體。托管記憶體釋放就由GC（Garbage Collector）來負責。我們要進一步講述的就是這個GC，但是在這之前要先講一下托管代碼中記憶體的配置設定，托管堆中記憶體的配置設定是順序的，也就是說一個挨着一個的配置設定。這樣記憶體配置設定的速度就要比原始程式高，但是高出的速度會被GC找回去。為什麼？看過GC的工作方式後你就會知道答案了。

GC工作方式

首先我們要知道托管代碼中的對象什麼時候回收我們管不了（除非用GC.Collect強迫GC回收，這不推薦，後面會說明為什麼）。GC會在它"高興"的時候執行一次回收（這有許多原因，比如記憶體不夠用時。這樣做是為了提高記憶體配置設定、回收的效率）。那麼如果我們用Destructor呢？同樣不行，因為.NET中Destructor的概念已經不存在了，它變成了Finalizer，這會在後面講到。目前請記住一個對象隻有在沒有任何引用的情況下才能夠被回收。為了說明這一點請看下面這一段代碼：

[C#]

object objA = new object();

object objB = objA;

objA = null;

// 強迫回收。

GC.Collect();

objB.ToString(); 

[Visual Basic]

Dim objA As New Object()

Dim objB As Object = objA

objA = Nothing

' 強迫回收。 

GC.Collect()

objB.ToString() 

這裡objA引用的對象并沒有被回收，因為這個對象還有另一個引用，ObjB。

對象在沒有任何引用後就有條件被回收了。當GC回收時，它會做以下幾步：

确定對象沒有任何引用。 

檢查對象是否在Finalizer表上有記錄。 

如果在Finalizer表上有記錄，那麼将記錄移到另外的一張表上，在這裡我們叫它Finalizer2。 

如果不在Finalizer2表上有記錄，那麼釋放記憶體。 

在Finalizer2表上的對象的Finalizer會在另外一個low priority的線程上執行後從表上删除。當對象被建立時GC會檢查對象是否有Finalizer，如果有就會在Finalizer表中添加紀錄。我們這裡所說的記錄其實就是指針。如果仔細看這幾個步驟，我們就會發現有Finalizer的對象第一次不會被回收，也就是，有Finalizer的對象要一次以上的Collect操作才會被回收，這樣就要慢一步，是以作者推薦除非是絕對需要不要建立Finalizer。為了證明GC确實這麼工作而不是作者胡說，我們将在對象的複活一章中給出一個示例，眼見為實，耳聽為虛嘛！^_^

GC為了提高回收的效率使用了Generation的概念，原理是這樣的，第一次回收之前建立的對象屬于Generation 0，之後，每次回收時這個Generation的号碼就會向後挪一，也就是說，第二次回收時原來的Generation 0變成了Generation 1，而在第一次回收後和第二次回收前建立的對象将屬于Generation 0。GC會先試着在屬于Generation 0的對象中回收，因為這些是最新的，是以最有可能會被回收，比如一些函數中的局部變量在退出函數時就沒有引用了（可被回收）。如果在Generation 0中回收了足夠的記憶體，那麼GC就不會再接着回收了，如果回收的還不夠，那麼GC就試着在Generation 1中回收，如果還不夠就在Generation 2中回收，以此類推。Generation也有個最大限制，根據Framework版本而定，可以用GC.MaxGeneration獲得。在回收了記憶體之後GC會重新排整記憶體，讓資料間沒有空格，這樣是因為CLR順序配置設定記憶體，是以記憶體之間不能有空着的記憶體。現在我們知道每次回收時都會浪費一定的CPU時間，這就是我說的一般不要手動GC.Collect的原因（除非你也像我一樣，寫一些有關GC的示例！^_^）。

Destructor的沒落，Finalizer的誕生

對于Visual Basic程式員來說這是個新概念，是以前一部分講述将着重對C++程式員。我們知道在C++中當對象被删除時（delete），Destructor中的代碼會馬上執行來做一些記憶體釋放工作（或其他）。不過在.NET中由于GC的特殊工作方式，Destructor并不實際存在，事實上，當我們用Destructor的文法時，編譯器會自動将它寫為protected virtual void Finalize()，這個方法就是我所說的Finalizer。就象它的名字所說，它用來結束某些事物，不是用來摧毀（Destruct）事物。在Visual Basic中它就是以Finalize方法的形式出現的，是以Visual Basic程式員就不用操心了。C#程式員得用Destructor的文法寫Finalizer，不過千萬不要弄混了，.NET中已經沒有Destructor了。C++中我們可以準确的知道什麼時候會執行Destructor，不過在.NET中我們不能知道什麼時候會執行Finalizer，因為它是在第一次對象回收操作後才執行的。我們也不能知道Finalizer的執行順序，也就是說同樣的情況下，A的Finalize可能先被執行，B的後執行，也可能A的後執行而B的先執行。也就是說，在Finalizer中我們的代碼不能有任何的時間邏輯。下面我們以計算一個類有多少個執行個體為示例，指出Finalizer與Destructor的不同并指出在Finalizer中有時間邏輯的錯誤，因為Visual Basic中沒有過Destructor是以示例隻有C#版：

public class CountObject {

  public static int Count = 0;

  public CountObject() {

    Count++;

  }

  ~CountObject() {

    Count--;

}

static void Main() {

  CountObject obj;

  for (int i = 0; i < 5; i++) {

    obj = null; // 這一步多餘，這麼寫隻是為了更清晰些！

   obj = new CountObject();

  // Count不會是1，因為Finalizer不會馬上被觸發，要等到有一次回收操作後才會被觸發。

  Console.WriteLine(CountObject.Count);

  Console.ReadLine();

注意以上代碼要是改用C++寫的話會發生記憶體洩漏，因為我們沒有用delete操作符手動清理記憶體，但是在托管代碼中卻不會發生記憶體洩漏，因為GC會自動檢測沒有引用了的對象并回收。這裡作者推薦你隻在實作IDisposable接口時配合使用Finalizer，在其他的情況下不要使用（可能會有特殊情況）。在非托管資源的釋放一章我們會更好的了解IDisposable接口，現在讓我們來做耶稣吧！

對象的複活

什麼？回收的對象也可以"複活"嗎？沒錯，雖然這麼說的定義不準确。讓我們先來看一段代碼：

public class Resurrection {

  public int Data;

  public Resurrection(int data) {

    this.Data = data;

  ~Resurrection() {

    Main.Instance = this;

public class Main {

  public static Resurrection Instance;

  public static void Main() {

    Instance = new Resurrection(1);

    Instance = null;

    GC.Collect();

    GC.WaitForPendingFinalizers();

    // 看到了嗎，在這裡“複活”了。

    Console.WriteLine(Instance.Data);

    Console.ReadLine();

Public Class Resurrection

  Public Data As Integer

  Public Sub New(ByVal data As Integer)

    Me.Data = data

  End Sub

  Protected Overrides Sub Finalize()

    Main.Instance = Me

    MyBase.Finalize()

End Class

Public Class Main

  Public Shared Instance As Resurrection

  Sub Main()

    Instance = New Resurrection(1)

    Instance = Nothing

    GC.Collect()

    GC.WaitForPendingFinalizers()

    ' 看到了嗎，在這裡“複活”了。

    Console.WriteLine(Instance.Data)

    Console.ReadLine()

你可能會問："既然這個對象能複活，那麼這個對象在程式結束後會被回收嗎？"。會，"為什麼？"。讓我們按照GC的工作方式走一遍你就明白是怎麼回事了。

1、執行Collect。檢查引用。沒問題，對象已經沒有引用了。

2、建立新執行個體時已經在Finalizer表上作了紀錄，是以我們檢查到了對象有Finalizer。

3、因為查到了Finalizer，是以将記錄移到Finalizer2表上。

4、在Finalizer2表上有記錄，是以不釋放記憶體。

5、Collect執行完畢。這時我們用了GC.WaitForPendingFinalizers，是以我們将等待所有Finalizer2表上的Finalizers的執行。

6、Finalizer執行後我們的Instance就又引用了我們的對象。（複活了）

7、再一次去除所有的引用。

8、執行Collect。檢查引用。沒問題。

9、由于上次已經将記錄從Finalizer表删除，是以這次沒有查到對象有Finalizer。

10、在Finalizer2表上也不存在，是以對象的記憶體被釋放了。

現在你明白原因了，讓我來告訴你"複活"的用處。嗯，這個……好吧，我不知道。其實，複活沒有什麼用處，而且這樣做也非常的危險。看來這隻能說是GC機制的漏洞（請參看GC.ReRegisterForFinalize再動腦筋想一下就知道為什麼可以說是漏洞了）。作者建議大家忘掉有什麼複活，避免這類的使用。可能你會問："那你幹嗎還要對我們說這些？"我說這些為的是讓大家更好的了解GC的工作機制！^_^

非托管資源的釋放

到現在為止，我們說了托管記憶體的管理，那麼當我們利用如資料庫、檔案等非托管資源時呢？這時我們就要用到.NET Framework中的标準：IDisposable接口。按照标準，所有有需要手動釋放非托管資源的類都得實作此接口。這個接口隻有一個方法，Dispose()，不過有相對的Guidelines訓示如何實作此接口，在這裡我向大家說一說。實作IDisposable這個接口的類需要有這樣的結構：

public class Base : IDisposable {

  public void Dispose() {

    this.Dispose(true);

    GC.SupressFinalize(this);

  protected virtual void Dispose(bool disposing) {

    if (disposing) {

      // 托管類

    }

    // 非托管資源釋放

  ~Base() {

    this.Dispose(false);

public class Derive : Base {

  protected override void Dispose(bool disposing) {

    base.Dispose(disposing);

Public Class Base

  Implements IDisposable

  Public Overloads Sub Dispose() Implements IDisposable.Dispose

    Me.Dispose(True)

    GC.SuppressFinalize(Me)

  Protected Overloads Overridable Sub Dispose(ByVal disposing As Boolean)

    If disposing Then

      ' 托管類

    End If

    ' 非托管資源釋放

    Me.Dispose(False)

Public Class Derive

  Inherits Base

  Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)

    MyBase.Dispose(disposing)

為什麼要這樣設計呢？讓我在後面解說一下。現在我們講講實作這個Dispose方法的幾個準則：

它不能扔出任何錯誤，重複的調用也不能扔出錯誤。也就是說，如果我已經調用了一個對象的Dispose，當我第二次調用Dispose的時候程式不應該出錯，簡單地說程式在第二次調用Dispose時不會做任何事。這些可以通過一個flag或多重if判斷實作。 

一個對象的Dispose要做到釋放這個對象的所有資源。拿一個繼承類為例，繼承類中用到了非托管資源是以它實作了IDisposable接口，如果繼承類的基類也用到了非托管資源那麼基類也得被釋放，基類的資源如何在繼承類中釋放呢？當然是通過一個virtual/Overridable方法了，這樣我們能保證每個Dispose都被調用到。這就是為什麼我們的設計有一個virtual/Overridable的Dispose方法。注意我們首先要釋放繼承類的資源然後再釋放基類的資源。 

因為非托管資源一定要被保障正确釋放是以我們要定義一個Finalizer來避免程式員忘了調用Dispose的情況。上面的設計就采用了這種形式。如果我們手動調用Dispose方法就沒有必要再保留Finalizer了，是以在Dispose中我們用了GC.SupressFinalize将對象從Finalizer表去掉，這樣再回收時速度會更快。 

那麼那個disposing和"托管類"是怎麼回事呢？是這樣：在"托管類"中寫所有你想在調用Dispose時讓其處于可釋放狀态的托管代碼。還記得我們說過我們不知道托管代碼是什麼時候釋放的嗎？在這裡我們隻是去掉成員對象的引用讓它處于可被回收狀态，并不是直接釋放記憶體。在"托管類"中這裡我們也要寫上所有實作了IDisposable的成員對象，因為他們也有Dispose，是以也需要在對象的Dispose中調用他們的Dispose，這樣才能保證第二個準則。disposing是為了區分Dispose的調用方法，如果我們手動調用那麼為了第二個準則"托管類"部分當然得執行，但如果是Finalizer調用的Dispose，這時候對象已經沒有任何引用，也就是說對象的成員自然也就不存在了（無引用），也就沒有必要執行"托管類"部分了，因為他們已經處于可被回收狀态了。好了，這就是IDisposable接口的全部了。現在讓我們來回想一下，以前我們可能認為有了Dispose記憶體就會馬上被釋放，這是錯誤的。隻有非托管記憶體才會被馬上釋放，托管記憶體的釋放由GC管理，我們不用管。

弱引用的使用

A = B，我們稱這樣的引用叫做強引用，GC就是通過檢查強引用來決定一個對象是否是可以回收的。另外還有一種引用稱作弱引用（WeakReference），這種引用不影響GC回收，這就是它的用處所在。你會問到底有什麼用處。現在我們來假設我們有一個很胖的對象，也就是說它占用很多記憶體。我們用過了這個對象，打算将它的引用去掉好讓GC可以回收記憶體，但是功夫不大我們又需要這個對象了，沒辦法，重新建立執行個體，怎麼建立這麼慢啊？有什麼辦法解決這樣的問題？有，将對象留在記憶體中不就快了嘛！不過我們不想這樣胖得對象總占着記憶體，而我們也不想總是建立這樣胖的新執行個體，因為這樣很耗時。那怎麼辦……？聰明的朋友一定已經猜到了我要說解決方法是弱引用。不錯，就是它。我們可以建立一個這個胖對象的弱引用，這樣在記憶體不夠時GC可以回收，不影響記憶體使用，而在沒有被GC回收前我們還可以再次利用該對象。這裡有一個示例：

public class Fat {

  public Fat(int data) {

    Fat oFat = new Fat(1);

    WeakReference oFatRef = new WeakReference(oFat);

    // 從這裡開始，Fat對象可以被回收了。

    oFat = null;

    if (oFatRef.IsAlive) {

      Console.WriteLine(((Fat) oFatRef.Target).Data); // 1

    // 強制回收。

    Console.WriteLine(oFatRef.IsAlive); // False

Public Class Fat

Public Module Main

    Dim oFat As New Fat(1)

    Dim oFatRef As New WeakReference(oFat)

    ' 從這裡開始，Fat對象可以被回收了。

    oFat = Nothing

    If oFatRef.IsAlive Then

      Console.WriteLine(DirectCast(oFatRef.Target, Fat).Data) ' 1

    ' 強制回收。

    Console.WriteLine(oFatRef.IsAlive) ' False

End Module

這裡我們的Fat其實并不是很胖，但是可以展現示例的本意：如何使用弱引用。那如果Fat有Finalizer呢，會怎樣？如果Fat有Finalizer那麼我們可能會用到WeakReference的另一個構造函數，當中有一參數叫做TrackResurrection，如果是True，隻要Fat的記憶體沒被釋放我們就可以用它，也就是說Fat的Finalizer執行後我們還是可以恢複Fat（相當于第一次回收操作後還可恢複Fat）；如果TrackResurrection是False，那麼第一次回收操作後就不能恢複Fat對象了。

總結

我在這裡寫出了正篇文章的要點：

一個對象隻當在沒有任何引用的情況下才會被回收。 

一個對象的記憶體不是馬上釋放的，GC會在任何時候将其回收。 

一般情況下不要強制回收工作。 

如果沒有特殊的需要不要寫Finalizer。 

不要在Finalizer中寫一些有時間邏輯的代碼。 

在任何有非托管資源或含有Dispose的成員的類中實作IDisposable接口。 

按照給出的Dispose設計寫自己的Dispose代碼。 

當用胖對象時可以考慮弱引用的使用。 

好了，就說到這裡了，希望對GC的了解會讓您的代碼更加穩固，更加簡潔，更加快！更重要的，不再會有記憶體管理問題，無論是托管還是非托管！

參考資訊

1、GC Class

ms-help://MS.VSCC/MS.MSDNVS.2052/cpref/html/frlrfSystemGCClassTopic.htm

2、Programming For Garbage Collection

ms-help://MS.VSCC/MS.MSDNVS.2052/cpguide/html/cpconprogrammingessentialsforgarbagecollection.htm

3、Curso de Erik, Septima Entrega (西班牙語)

http://guille.costasol.net/NET/cursoCSharpErik/Entrega7/Entrega7.htm 

專注于企業資訊化，最近對股票資料分析較為感興趣，可免費分享股票個股主力資金實時變化趨勢分析工具，股票交流QQ群：457394862

本文轉自滄海-重慶部落格園部落格，原文連結：http://www.cnblogs.com/omygod/archive/2006/11/08/554565.html，如需轉載請自行聯系原作者