本文講解的是你在建立包含內存以外資源的類型，特別是處置非內存資源的時候，如何編寫自己的資源管理代碼。

　　我們已經知道了處置那些占用非受控（unmanaged）資源的對象的重要性，現在應該編寫資源管理代碼來處置那些包含非內存資源的類型了。整個.NET框架組件都使用一個標準的模式來處理非內存資源。使用你建立的類型的用戶也希望你遵循這個標準的模式。標準的處理模式的思想是這樣的：當客戶端記得的時候使用IDisposable接口釋放你的非受控資源，當客戶端忘記的時候防護性地使用終結器（finalizer）。它與垃圾收集器（Garbage Collector）一起工作，確保只在必要的時候該對象才受到與終結器相關的性能影響。這是處理非受控資源的一條很好的途徑，因此我們應該徹底地認識它。

　　類層次體系中的根基類（root base class）必須實現IDisposable接口以釋放資源。這個類型還必須添加一個作為防御機制的終結器。所有這些程序都把釋放資源的工作委托給一個虛擬的方法，衍生的類可以根據自己的資源管理需求來重載該方法。只要衍生的類必須釋放自己的資源，并且它必須調用該函數的基類版本的時候，它才需要重載這個虛擬方法。

　　開始的時候，如果你的類使用了非內存資源，它就必須含有一個終結器。你不能依賴客戶端總是調用Dispose()方法。因為當它們忘記這樣做的時候，你就面臨資源泄漏的問題。沒有調用Dispose是它們的問題，但是你卻有過失。用于保證非內存資源被正確地釋放的唯一途徑是建立終結器。

　　當垃圾收集器運行的時候，它立即從內存中刪除所有不帶終結器的垃圾對象。所有帶有終結器的對象仍然存在于內存中。這些對象都被添加到終結隊列，垃圾收集器引發一個新線程，周期性地在這些對象上運行終結器。在這些終結程序線程完成自己的工作之后，就可以從內存中刪除垃圾對象了。需要終結的對象在內存中停留的時間比沒有終結器的對象停留的時間長很多。但是你別無選擇。如果要使程序有防護性，在類型包含非受控資源的時候，你必須編寫一個終結器。但是也不用擔心性能問題。下一步確保了客戶端避免與終結相關的性能開銷。
實現IDisposable接口是一種標準的途徑，它通知用戶和運行時系統持有資源的對象必須及時地釋放。IDisposable接口僅僅包含一個方法：

public interface IDisposable
{
　void Dispose( );
}

　　你對IDisposable.Dispose()方法的實現（implementation）負責下面四個事務：

　　1、釋放所有的非受控資源。

　　2、釋放所有的受控資源（包括未解開事件）。

　　3、設置標志表明該對象已經被處理過了。你必須在自己的公共方法中檢查這種狀態標志并拋出ObjectDisposed異常（如果某個對象被處理過之后再次被調用的話）。

　　4、禁止終結操作（finalization）。你調用GC.SuppressFinalize(this)來完成這種事務。

　　通過實現IDisposable接口你完成了兩個事務：你為客戶端及時地釋放自己持有的所有受控資源提供了機制；你為客戶端提供了一種釋放非受控資源的標準途徑。這是一個很大的進步。當你在類型中實現了Idisposable接口的時候，客戶端可以避免終結操作的開銷，你的類就成為.NET世界中的"良民"了。

　　但是在你建立的這種機制中仍然存在一些問題。怎樣在衍生類清理自己資源的時候同時也讓基類能夠清理資源？如果衍生類重載了終結操作，或者添加了自己的IDisposable實現，那么這些方法必須調用基類，否則，基類就不能正確地進行清理操作。同樣，finalize（終結操作）和Dispose參與分擔了一些相同的職責。Finalize方法和Dispose方法的代碼幾乎相同。而且在重載接口函數后并不像你預料的那樣工作。標準的Dispose模式中的第三個方法是一個受保護的虛擬輔助函數，它分解出這些共同的事務，并給衍生類添加一個用于釋放資源的"鉤子（hook）"�；�類包含了核心接口的代碼。作為對Dispose()或終結操作的響應，該虛擬函數為衍生類清除資源提供了"鉤子"：

protected virtual void Dispose( bool isDisposing );

　　這個重載的方法實現支持finalize和Dispose的必要事務，由于它是虛擬的，它為所有的衍生類提供了一個入口點。衍生類可以重載這個方法，為清除自己的資源提供適當的實現，同時還可以調用基類版本。當isDisposing為真（true）的時候，你可以清除受控和非受控資源，當isDisposing為假（false）的時候，你只能清除非受控資源。在這兩種情況下，你都可以調用基類的Dispose(bool)方法，讓它清除自己的資源。

　　下面有一個簡短的例子，它演示了你在實現這種模式的時候所提供的代碼框架。MyResourceHog類演示了實現IDisposable接口、終結器的代碼，并建立了一個虛擬的Dispose方法：

public class MyResourceHog : IDisposable
{
　// 已經被處理過的標記
　private bool _alreadyDisposed = false;
　// 終結器。調用虛擬的Dispose方法
　~MyResourceHog()
　{
　　Dispose( false );
　}

　// IDisposable的實現
　// 調用虛擬的Dispose方法。禁止Finalization（終結操作）
　public void Dispose()
　{
　　Dispose( true );
　　GC.SuppressFinalize( true );
　}

　// 虛擬的Dispose方法
　protected virtual void Dispose( bool isDisposing )
　{
　　// 不要多次處理
　　if ( _alreadyDisposed )
　　　return;
　　if ( isDisposing )
　　{
　　　// TODO: 此處釋放受控資源
　　}
　　// TODO: 此處釋放非受控資源。設置被處理過標記
　　_alreadyDisposed = true;
　}
}

　　如果衍生類需要執行另外的清除操作，它應該實現受保護的Dispose方法：

public class DerivedResourceHog : MyResourceHog
{
　// 它有自己的被處理過標記
　private bool _disposed = false;

　protected override void Dispose( bool isDisposing )
　{
　　// 不要多次處理
　　if ( _disposed )
　　　return;
　　if ( isDisposing )
　　{
　　　// TODO: 此處釋放受控資源
　　}
　　// TODO: 此處釋放所有受控資源
　
　　// 讓基類釋放自己的資源。基類負責調用GC.SuppressFinalize( )
　　base.Dispose( isDisposing );

　　// 設置衍生類的被處理過標記
　_disposed = true;
　}
}

　　請注意，基類和衍生類都包含該對象的被處理過（disposed）標記。這純粹是起保護作用。復制這個標記可以封裝構成某個對象的所有類釋放資源時產生的任何可能的錯誤。

　　你必須編寫防護性的Dispose和finalize。對象的處理可以按任意次序進行，你可能會遇到在調用自己類型的成員對象的Dispose()方法之前，該對象已經被處理過了。你不應該認為這是問題，因為Dispose()方法會被多次調用。如果它在已經被處理過的對象上被調用，它就不執行任何事務。Finalizer（終結器）也有類似的規則。如果你引用的對象仍然存在于內存中，你就沒有必要檢查空引用（null reference）。但是，你引用的任何對象都可能被處理了，它也可能已經被終結了。

　　這為我帶來了與處理或清除相關的任何方法的最重要的建議：你應該僅僅釋放資源，在dispose方法中不要執行任何其它操作。如果你在Dispose或finalize方法中執行其它操作，都可能給對象的生命周期帶來嚴重的不良影響。對象在被構造的時候才"出生"，當垃圾收集器收回它們的時候才"死亡"。當你的程序再也不能訪問它們的時候，你可以認為它們處于"昏睡"狀態。如果你不能到達（reach）某個對象，你就不能調用它的方法，對于所有的意圖和目的來說，它是死的。但是帶有終結器的對象被宣布死亡之前還有最后一口氣。終結器除了清理非受控資源之外不應該執行其它任何操作。如果某個終結器由于什么原因使某個對象又可以到達了，那么該對象就恢復（resurrected）了。即使它是從"昏睡"狀態醒來的，它也是"活著"的。下面是一個很明顯的例子：

public class BadClass
{
　// 保存某個全局對象的引用
　private readonly ArrayList _finalizedList;
　private string _msg;

　public BadClass( ArrayList badList, string msg )
　{
　　// 緩沖該引用
　　_finalizedList = badList;
　　_msg = (string)msg.Clone();
　}

　~BadClass()
　{
　　// 把該對象添加到列表中。這個對象是可到達的，不再是垃圾了。它回來了！
　　_finalizedList.Add( this );
　}
}

　　當某個BadClass對象執行自己的終結器的時候，它向全局列表上添加了對自己的引用。這僅僅使自己可到達了，它活了過來！但是這樣操作所帶來的問題使任何人都會感到膽怯。該對象已經被終結了，因此垃圾收集器相信不用再次調用它的終結器了。你真的需要終結一個被恢復的對象的時候，終結操作卻不會發生了。其次，你的一些資源可能不能用了。GC不會把終結器隊列中的對象可以到達的任何對象從內存中移除，但是它可能已經終結了這些對象。如果是這樣的話，那些對象一定不能再次使用了。盡管BadClass的成員仍然存在于內存中，它們卻像被處理過或被終結了一樣。在C#語言中沒有控制終結次序的途徑。你不能使這種構造工作更可靠。不要嘗試！

　　除了學院的練習作業之外，我從來沒有見到過如此明顯地使用被恢復對象的代碼。但是我看到有些代碼有這個傾向，它們在終結器中試圖執行某些實際工作，當終結器調用的某些函數保存了對該對象的引用的時候，它就正在把對象變成活動的狀態。原則上我們必須非常仔細地檢查finalizer和Dispose方法中任何代碼。如果有些代碼除了釋放資源之外還執行了其它的操作，我們就需要再檢查一次。這些操作在未來可能引起程序bug。請移除這些操作，并確保finalizer和Dispose()方法只釋放資源，不作其它任務事務。

　　在受控環境中，你不必為自己建立的每個類型編寫終結器，你只需要為存儲非受控類型，或者包含了實現IDisposable接口的成員的類型編寫終結器。即使你只需要Disposable接口，不需要finalizer，也應該同時實現整個模式。否則，你會使衍生類的標準Dispose思想的實現變得很復雜，從而限制了衍生類的功能。請遵循前面談到的標準的Dispose思想，這將使你、你的類的用戶、從你的類型建立衍生類的用戶的生活更加輕松。