本文講解的是你在建立包含內存以外資源的類型，特別是處置非內存資源的時候，如何編寫自己的資源管理代碼。
我們已經知道了處置那些占用非受控（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)方法，讓它清除自己的資源。
