我們已經討論過，處理一個占用了非托管資源對象是很重要的。現在是時候 來討論如何寫代碼來管理這些類占用的非內存資源了。一個標准的模式就是利用 .Net框架提供的方法處理非內存資源。你的用戶也希望你遵守這個標准的模式。也就是通過實現IDisposable接口來釋放非托管的資源，當然是在用戶記得調用 它的時候，但如果用戶忘記了，析構函數也會被動的執行。它是和垃圾回收器一 起工作的，確保在一些必要時候，你的對象只會受到因析構函數而造成的性能損 失。這正是管理非托管資源的好方法，因此有必要徹底的弄明白它。
處 在類繼承關系中頂層的基類應該實現IDisposable接口來釋放資源。這個類型也 應該添加一個析構函數，做為最後的被動機制。這兩個方法都應該是用虛方法來 釋放資源，這樣可以讓它的派生類重載這個函數來釋放它們自己的資源。派生類 只有在它自己須要釋放資源時才重載這個函數，並且一定要記得調用基類的方法 。
開始時，如果你的類使用了非內存資源，則一定得有一個析構函數。 你不能指望你的用戶總是記得調用Dispose方法，否則當他們忘記時，你會丟失 一些資源。這或許是因為他們沒有調用Dispose的錯誤，但你也有責任。唯一可 以確保非內存資源可以恰當釋放的方法就是創建一個析構函數。所以，添加一個 析構函數吧!
當垃圾回收器運行時，它會直接從內存中移除不用析構的垃 圾對象。而其它有析構函數的對象還保留在內存中。這些對象被添加到一個析構 隊列中，垃圾回收器會起動一個線程專門來析構這些對象。當析構線程完成它的 工作後，這些垃圾對象就可以從內存中移除了。就是說，須要析構的對象比不須 要析構的對象在內存中待的時間要長。但你沒得選擇。如果你是采用的這種被動 模式，當你的類型占用非托管資源時，你就必須寫一個析構函數。但目前你還不 用擔心性能問題，下一步就保證你的用戶使用更加簡單，而且可以避免因為析構 函數而造成的性能損失。
實現IDisposable接口是一個標准的模式來告訴 用戶和進行時系統：你的對象占有資源而且必須及時的釋放。IDisposable接口 只有一個方法：
public interface IDisposable
{
void Dispose( );
}
實現IDisposable.Dispose()方法有責 任完成下面的任務：
1、感知所有的非托管資源。
2、感知所有的 托管資源(包括卸載一些事件)。
3、設置一個安全的標記來標識對象已經 被處理。如果在已經處理過的對象上調用任何方法時，你可以檢驗這個標記並且 拋出一個ObjectDisposed的異常。
4、阻止析構。你要調用 GC.SuppressFinalize(this)來完成最後的工作。
通過實現IDisposable 接口，你寫成了兩件事：第一就是提供了一個機制來及時的釋放所有占用的托管 資源(譯注：這裡就是指托管資源，當實現了這個接口後，可以通過調用Dispose 來立即釋放托管資源)，另一個就是你提供了一個標准的模式讓用戶來釋放非托 管資源。這是十分重要的，當你在你的類型上實現了IDisposable接口以後，用 戶就可以避免析構時的損失。你的類就成了.Net社區中表現相當良好的成員。
但在你創建的機制中還是存在一些漏洞。如何讓一個派生類清理自己的 資源，同時還可以讓基類很好的再做資源清理呢？(譯注：因為調用Dispose方法 時，必須調用基類的Dispose，當然是在基類有這個方法時。但前面說過，我們 只有一個標記來標識對象是否處理過，不管先調用那個，總得有一個方法不能處 理這個標記，而這就存在隱患) 如果基類重載了析構函數，或者自己添加實現了 IDisposable接口，而這些方法又都是必須調用基類的方法的；否則，基類無法 恰當的釋放資源。同樣，析構和處理共享了一些相同的職責：幾乎可以肯定你是 復制了析構方法和處理方法之間的代碼。正如你會在原則26中學到的，重載接口 的方法根本沒有如你所期望的那樣工作。Dispose標准模式中的第三個方法，通 過一個受保護的輔助性虛函數，制造出它們的常規任務並且掛接到派生類來釋放 資源。基類包含接口的核心代碼， 派生類提供的Dispose()虛函數或者析構函數 來負責清理資源：
protected virtual void Dispose( bool isDisposing );
重載的方法同時完成析構和處理必須提供的任務 ，又因為它是虛函數，它為所有的派生類提供函數入口點。派生類可以重載這個 函數，提供恰當的實現來釋放它自己的資源，並且調用基類的函數。當
isDisposing為true時你可能同時清理托管資源和非托管資源，當 isDisposing為false時你只能清理非托管資源。兩種情況下，都可以調用基類的 Dispose(bool)方法讓它去清理它自己的資源。
當你實現這樣的模式時， 這裡有一個簡單的例子。MyResourceHog 類展示了IDisposable的實現，一個析 構函數，並且創建了一個虛的Dispose方法：
public class MyResourceHog : IDisposable
{
// Flag for already disposed
private bool _alreadyDisposed = false;
// finalizer:
// Call the virtual Dispose method.
~MyResourceHog()
{
Dispose( false );
}
// Implementation of IDisposable.
// Call the virtual Dispose method.
// Suppress Finalization.
public void Dispose()
{
Dispose( true );
GC.SuppressFinalize( true );
}
// Virtual Dispose method
protected virtual void Dispose( bool isDisposing )
{
// Don't dispose more than once.
if ( _alreadyDisposed )
return;
if ( isDisposing )
{
// TODO: free managed resources here.
}
// TODO: free unmanaged resources here.
// Set disposed flag:
_alreadyDisposed = true;
}
}
如果派生類有另外 的清理任務，就讓它實現Dispose方法：
public class DerivedResourceHog : MyResourceHog
{
// Have its own disposed flag.
private bool _disposed = false;
protected override void Dispose( bool isDisposing )
{
// Don't dispose more than once.
if ( _disposed )
return;
if ( isDisposing )
{
// TODO: free managed resources here.
}
// TODO: free unmanaged resources here.
// Let the base class free its resources.
// Base class is responsible for calling
// GC.SuppressFinalize( )
base.Dispose( isDisposing );
// Set derived class disposed flag:
_disposed = true;
}
}
注和意，派生類和基類都有一個處理狀態的標記， 這完全是被動的。重制的標記掩蓋了在處理時任何可能發生的錯誤，而且是單一 的類型處理，而不是處理構成這個對象的所有類型。(譯注：就是基類與子類各 自標記一個，互不影響。)
你應該被動的寫處理方法和析構函數，處理對 象可能以任何順序發生，你可能會遇到這種情況：你的類中某個成員在你調用 Dispose方法以前已經被處理過了。你沒有看到這種情況是因為Dispose()方法是 可以多次調用的。如果在一個已經被處理過的對象上調用該方法，就什麼也不發 生。析構函數也有同樣的規則。任何對象的引用存在於內存中時，你不用檢測 null引用。然而，你引用的對象可能已經處理掉了，或者它已經析構了。
這就引入用了一個非常重要的忠告：對於任何與處理和資源清理相關的 方法，你必須只釋放資源! 不要在處理過程中添加其它任何的任務。你在處理和 清理中添加其它任務時，可能會在對象的生存期中遇到一些嚴重而繁雜的問題。 對象在你創建它時出生，在垃圾回收器認領它時死亡。你可以認為當你的程序不 能再訪問它們時，它們是睡眠的。你無法訪問對象，無法調用對象的方法。種種 跡象表明，它們就像是死的。但對象在宣布死亡前，析構函數還有最後一氣。析 構函數什麼也不應該做，就是清理非托管資源。如果析構函數通過某些方法讓對 象又變得可訪問，那麼它就復活了。(譯注：析構函數不是用戶調用的，也不 由.Net系統調用，而是在由GC產生的額外線程上運行的) 它又活了，但這並不好 。即使是它是從睡眼中喚醒的。這裡有一個明顯的例子：
public class BadClass
{
// Store a reference to a global object:
private readonly ArrayList _finalizedList;
private string _msg;
public BadClass( ArrayList badList, string msg )
{
// cache the reference:
_finalizedList = badList;
_msg = (string)msg.Clone();
}
~BadClass()
{
// Add this object to the list.
// This object is reachable, no
// longer garbage. It's Back!
_finalizedList.Add( this );
}
}
當一個BadClass對象的析構函數執行時，它把自己的一 個引用添加到了全局的鏈表中。這使得它自己又是可達的，它就又活了。前面向 你介紹的這個方法會遇到一些讓人畏縮的難題。對象已經被析構了，所以垃圾回 收器從此相信再也不用調用它的析構函數了。如果你實際要析構一個可達對象， 這將不會成功。其次，你的一些資源可能不再有用。GC不再從內存上移除那些只 被析構隊列引用的對象，但它們可能已經析構了。如果是這樣，它們很可能已經 不能使用了。(譯注：也就是說利用上面的那個方法讓對象復活後，很有可能對 象是不可用的。)盡管BadClass所擁有的成員還在內存裡，它們像是可以被析構 或者處理，但C#語言沒有一個方法可以讓你控制析構的次序，你不能讓這樣的結 構可靠的運行。不要嘗試。
我還沒有看到這樣的代碼：用這樣明顯的方 式來復活一個對象，除非是學術上的練習。但我看過這樣的代碼，析構函數試圖 完成一些實質的工作，最後還通過析構函數的調用把引用放到對象中，從而把自 己復活。析構函數裡面的代碼看上去是精心設計的，另外還有處理函數裡的。再 檢查一遍，這些代碼是做了其它事情，而不是釋放資源!這些行為會為你的應用 程序在後期的運行中產生很多BUG。刪除這些方法，確保析構函數和Dispose()方 法除了清理資源外，什麼也不做。
在托管環境裡，你不用為每一個創建 的類寫析構函數；只有須要釋放一些使用的非托管資源時才添加，或者你的類所 包含的成員有實現了IDisposable接口的時候也要添加。即使如此，你也只用實 現IDisposable接口完成所有的功能就行了，不用析構函數。否則，你會限制你 的派生類實現實現標准的Dispose習慣。 遵守這個我所講敘的標准的Dispose習 慣。這會讓你的程序生活變得輕松，也為你的用戶，也為那些從你的類創建派生 類的人。
返回教程目錄
