IDisposableとファイナライザーを適用する方法：3つの簡単なルール

翻訳者から

メモリリークとイベントの正しい実装についての話の後、メモリ管理のトピックで気に入った記事の別の翻訳を投稿します。 Disposeパターンのいくつかの異なる実装を確認しましたが、時には互いに矛盾することさえありました。 この記事では、著者はIDisposableインターフェイスをいつ実装するか、いつファイナライザーを使用するか、いつ-一緒に使用するかについて、明確で明確な説明を提供しました。

IDisposableとファイナライザーを適用する方法：3つの簡単なルール

IDisposableの使用に関するMicrosoftのドキュメントはかなりわかりにくいです。 実際、3つの単純なルールに単純化されています。

ルール1：適用しない（本当に必要になるまで）

IDisposableインターフェイスを実装することにより、デストラクタを作成していません。 .NET環境には、複数の変数をnullにしないように十分に機能するガベージコレクターがあります。

IDisposableを実装する必要がある状況は2つだけです。 クラスを見て、このインターフェイスが必要かどうかを判断します。

• クラスにアンマネージリソースがあります
• クラスは（IDisposable）リソースを管理しています

リソースは、これらのリソースが属するクラスのみを解放する必要があることに注意してください。 特に、クラスは共有リソースへのリンクを持っている可能性があります-この場合、他のクラスがこのリソースを使用し続ける可能性があるため、このリソースを解放しないでください。

多くの初心者プログラマーが書くコードの例を次に示します。

//    IDisposable. public sealed class ErrorList : IDisposable { private string category; private List<string> errors; public ErrorList(string category) { this.category = category; this.errors = new List<string>(); } // ( / ) //  public void Dispose() { if (this.errors != null) { this.errors.Clear(); this.errors = null; } } } 

一部のプログラマー（特に以前にC ++で作業したことのあるプログラマー）は、さらに進んでファイナライザーを追加します。

 //       IDisposable. public sealed class ErrorList : IDisposable { private string category; private List<string> errors; public ErrorList(string category) { this.category = category; this.errors = new List<string>(); } // ( / ) //   public void Dispose() { if (this.errors != null) { this.errors.Clear(); this.errors = null; } } ~ErrorList() { //  !</font> //            !</font> this.Dispose(); } } 

例は、説明したクラスのIDisposableの正しい実装です。

 //     IDisposable. public sealed class ErrorList { private string category; private List<string> errors; public ErrorList(string category) { this.category = category; this.errors = new List<string>(); } } 

わかった。 このクラスのIDisposableインターフェイスの適切な使用-適用しないでください！ ErrorListインスタンスが使用できなくなると、ガベージコレクターは使用中のメモリを自動的に解放します。

IDisposableを適用するためのこれら2つの基準を覚えておいてください-クラスはアンマネージまたはマネージリソースを所有する必要があります。 あなたはポイントを通過することができます：

1. ErrorListクラスはアンマネージリソースを所有していますか？ いいえ、所有していません。
2. ErrorListクラスには管理対象リソースがありますか？ 「マネージリソース」はIDisposableを実装するクラスであることに注意してください。 クラスの各メンバーを確認します。
1.文字列クラスはIDisposableを実装していますか？ いいえ、そうではありません。
2. ListクラスはIDisposableを実装していますか？ いいえ、そうではありません。
3. IDisposableを実装しているメンバーがいない場合、ErrorListクラスは管理対象リソースを所有していません。
3. ErrorListはマネージリソースもアンマネージリソースも所有しないため、IDisposableインターフェイスの実装は必要ありません。

ルール2：管理対象リソースを所有するクラスの場合、IDisposableを実装します（ファイナライザーは実装しません）

IDisposableインターフェイスには、Disposeという1つのメソッドのみがあります。 このメソッドを実装する場合、1つの重要な義務を果たす必要があります。Disposeへの複数の呼び出しでもエラーなしで発生する必要があります。

Disposeメソッドの実装は、このメソッドがファイナライザースレッドから呼び出されていないこと、オブジェクトのインスタンスがガベージコレクターによってまだ収集されていないこと、およびオブジェクトのコンストラクターが正常に完了したことを意味します。 これらの前提により、管理対象リソースへのアクセスが安全になります。

管理対象リソースのみを所有するクラスにファイナライザーを配置すると、エラーが発生する可能性があります。 このサンプルコードは、ファイナライザースレッドで例外をスローし、アプリケーションを中断する可能性があります。

 //       . public sealed class SingleApplicationInstance { private Mutex namedMutex; private bool namedMutexCreatedNew; public SingleApplicationInstance(string applicationName) { this.namedMutex = new Mutex(false, applicationName, out namedMutexCreatedNew); } public bool AlreadyExisted { get { return !this.namedMutexCreatedNew; } } ~SingleApplicationInstance() { // , , !!! this.namedMutex.Close(); } } 

SingleApplicationInstanceがIDisposableインターフェイスを実装するかどうかは問題ではありません。ファイナライザで管理対象オブジェクトにアクセスするという事実は、エラーに対する正しい方法です。

ファイナライザがなく、IDisposableインターフェイスが正しく、しかし複雑すぎる方法で実装されているクラスの例を次に示します。

 //     IDisposable. public sealed class SingleApplicationInstance : IDisposable { private Mutex namedMutex; private bool namedMutexCreatedNew; public SingleApplicationInstance(string applicationName) { this.namedMutex = new Mutex(false, applicationName, out namedMutexCreatedNew); } public bool AlreadyExisted { get { return !this.namedMutexCreatedNew; } } //   public void Dispose() { if (namedMutex != null) { namedMutex.Close(); namedMutex = null; } } } 

クラスが管理対象リソースを所有している場合、そのクラスでDisposeメソッドを呼び出すことができます。 追加のコードは必要ありません。 一部のクラスでは「Dispose」の名前を「Close」に変更しているため、Disposeメソッドの実装は、DisposeおよびCloseメソッドの呼び出しのみで構成されている場合があることに注意してください。

同等で簡単な実装：

 //    IDisposable. public sealed class SingleApplicationInstance : IDisposable { private Mutex namedMutex; private bool namedMutexCreatedNew; public SingleApplicationInstance(string applicationName) { this.namedMutex = new Mutex(false, applicationName, out namedMutexCreatedNew); } public bool AlreadyExisted { get { return !this.namedMutexCreatedNew; } } public void Dispose() { namedMutex.Close(); } } 

Disposeメソッドのこの実装は完全に安全です。 IDisposable子リソースの各実装は順番に安全であるため、必要に応じて何度でも呼び出すことができます。 この推移的なプロパティを使用して、Disposeメソッドのこのような単純な実装を記述する必要があります。

ルール3：管理されていないリソースを所有するクラスの場合、IDisposableとファイナライザーを実装します

管理されていないリソースを1つ所有するクラスは、他のことを一切行うべきではありません。 彼の唯一の義務は、このリソースを閉じることです。

クラスは、いくつかのアンマネージリソースを担当するべきではありません。 1つのリソースを正しく解放することは非常に難しく、複数の管理されていないリソースを含むクラスを記述することはさらに困難です。

クラスは、管理されたリソースと管理されていないリソースを一緒に扱うべきではありません。 そのようなクラスを作成することは可能ですが、正しく行うことは非常に困難です。 私を信じて より良いとしようとしないでください。 クラスにエラーがなくても、メンテナンスは悪夢に変わります。 .NET 2.0が登場するまでに、MicrosoftはBCL（基本クラスライブラリ）から多くのクラスを書き直し、それらをアンマネージリソースとマネージリソースを所有するクラスに分割しました。

注：IDisposableに関するこのような複雑な公式ドキュメントの存在は、Microsoftがクラスに両方のタイプのリソースが含まれると信じているという事実によるものです。 これは、下位互換性のために残された.NET 1.0の遺物です。 Microsoftで作成されたクラスでさえ、この古いパターンに従いません（.NET 2.0では、この記事で説明したパターンを使用して変更されました）。 FxCopは、 IDisposableを「正しく」実装する必要があると言います（つまり、古いテンプレートを使用します）。 彼の言うことを聞かないでください-FxCopは間違っています。

クラスは次のようになります。

 //    IDisposable. //       SafeHandle. public sealed class WindowStationHandle : IDisposable { public WindowStationHandle(IntPtr handle) { this.Handle = handle; } public WindowStationHandle() : this(IntPtr.Zero) { } public bool IsInvalid { get { return (this.Handle == IntPtr.Zero); } } public IntPtr Handle { get; set; } private void CloseHandle() { //   ,    if (this.IsInvalid) { return; } //  ,   if (!NativeMethods.CloseWindowStation(this.Handle)) { Trace.WriteLine("CloseWindowStation: " + new Win32Exception().Message); } //     this.Handle = IntPtr.Zero; } public void Dispose() { this.CloseHandle(); GC.SuppressFinalize(this); } ~WindowStationHandle() { this.CloseHandle(); } } internal static partial class NativeMethods { [DllImport("user32.dll", SetLastError = true)] [return: MarshalAs(UnmanagedType.Bool)] internal static extern bool CloseWindowStation(IntPtr hWinSta); } 

Disposeメソッドの最後に、 GC.SuppressFinalize（this）の呼び出しがあります。 これにより、オブジェクトのファイナライザが呼び出されなくなります。

Disposeが明示的に呼び出されない場合、ファイナライザは最終的に機能し、ハンドルを閉じます。

CloseHandleメソッドは、最初にハンドルがnullかどうかを確認します。 次に、可能な例外をスローせずに閉じます。 CloseHandleはファイナライザから呼び出すことができ、例外をスローするとプロセスが停止します。 CloseHandleメソッドは、ハンドルをnullにすることで終了します。 T.O. 何度でも呼び出すことができます。 これにより、Disposeを繰り返し呼び出すことが安全になります。 Disposeにハンドルチェックを配置できますが、このチェックをCloseHandleに配置すると、nullハンドルをコンストラクターに渡して、それらをHandleプロパティに割り当てることができます。

CloseHandleの後にSuppressFinalizeが呼び出される理由は、ハンドルを閉じるときにDisposeでエラーが発生した場合、ファイナライザーが呼び出されるためです。 この理由は、Joe Duffyのブログ （ 詳細 は非常に良い記事です-およそPer。 ） で詳細に議論されましたが、かなり弱い議論ですが。 違いは、CloseHandleメソッドがファイナライザから呼び出されたときに異なる方法でハンドルを閉じた場合にのみ存在します。 もちろん、これは実行できますが、推奨されません。

重要！ WindowStationHandleクラスにはウィンドウレイアウトハンドルが含まれておらず、ウィンドウレイアウトの作成またはオープンについては何も知りません。 これらの関数は（ウィンドウに関連する他の関数と同様に）別のクラス（おそらく「WindowStation」）のタスクです。 これにより、正しい実装を作成できます。 例外がスローされるため、デザイナーが不完全な施設でも各ファイナライザを実行する必要があります。 実際には、これを行うのは難しく、これが、ラッパークラスをハンドルを閉じるクラスとラッパークラス自体に分割する必要があるもう1つの理由です。

注：上記のソリューションは最も単純であり、欠点があります。 たとえば、リソース割り当て関数が実行された直後にスレッドが終了すると、このリソースがリークする可能性があります。 IntPtrハンドルをラップする場合、 SafeHandleクラスから継承するのが最善です。 さらに進んで、リソースの信頼できるリリースを維持する必要がある場合、すべてがすぐに非常に混乱します （ 別の良い記事-約Per。 ）！