問題タブ [finalizer]

MSDNのコードサンプルを参照してください：（http://msdn.microsoft.com/en-us/library/b1yfkh5e (v=VS.100).aspx ）

Dispose（）実装では、GC.SupressFinalize（）;を呼び出しますが、オブジェクトをファイナライズするためのデストラクタを提供します。

GC.SuppressFinalize（）が呼び出されたときに、デストラクタに実装を提供する意味は何ですか？

意図が何であるか少し混乱していますか？

これは主に好奇心からです。

デバッグ/ロギング/プロファイリングの目的を除いて、誰かが Object.finalize() の適切な使用法に遭遇したかどうか、私はさまよっていましたか?

遭遇したことがない場合、良い使い方は何だと思いますか?

私は非決定論的破壊について混乱するのに忙しい。別の質問への回答で、デストラクタ/ファイナリザ（c＃でも同じであると想定しています。つまり、〜classname（）という関数）は高価であり、必須ではないというアドバイスを受けました。しかし、この例を見ると、デストラクタが使用されており、コメントからはそれが不可欠であるように思われます。これがどのように組み合わされるかについて誰かがアドバイスを受けました。コードからデストラクタを削除する必要がありますか？

再度、感謝します。

NativeDogC＃から使用する必要のあるC ++アンマネージクラスがあるため、ラッパークラスを作成しましたManagedDog。

すべてが順調で、私は次のようなクラスを使用します。

何が悪いのか分かりますか？時々非常に奇妙なことが起こり始めるまで、私は最初はどちらもしませんでした。基本的に、プログラムを呼び出しMyFunc()た後、ネイティブ関数FeedDogNative（上記のマーク(***)）のどこかにあるときにGCによって一時停止された場合、C＃MyFunc（ローカル）でも使用されなくなるため、マネージラッパーを収集できると見なされます。変数であり、FeedDogManaged呼び出し後には使用されません）、どちらでもFeedDogManaged。そして、これは実際に時々起こりました。GCはファイナライザーを呼び出します。ファイナライザーは、使用が終了していなくdeleteても、ネイティブの犬のオブジェクトです。FeedDogNativeそのため、アンマネージコードは削除されたポインターを使用しています。

どうすればこれを防ぐことができますか？私はいくつかの方法を考えることができます（たとえばdog、最後に使用するふりをするダミー呼び出しFeedDogManaged）が、推奨される方法は何でしょうか？

クラスに Finalize と Dispose を実装していました。親クラスに IDisposable を実装し、子クラスの Dispose(bool) オーバーロードをオーバーライドしました。よくわかりませんでした

1. 重複する isDisposed 変数を使用するかどうか (基本クラスに既に存在するため) かどうか?
2. 子クラスにもファイナライザを実装するかどうか

これらは両方とも、ここに示す例で行われます-

http://guides.brucejmack.biz/CodeRules/FxCop/Docs/Rules/Usage/DisposeMethodsShouldCallBaseClassDispose.html

このMSDNの記事の例には、これら2つのいずれもありません - http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx

一方、MSDN のこの例は完全ではありません - http://msdn.microsoft.com/en-us/library/ms182330.aspx

私の新しいクライアントの場所のコードレビューチェックリストには次のものがあります-

DisposeとFinalizeを実装するクラスは、Dispose実装でGC.SupressFinalizeを呼び出す必要があります

なんで？

IDisposableインターフェースを実装するクラスは、Dispose実装でGC.SupressFinalizeを呼び出す必要があるため、読み取らないでください。

または私は愚かな何かを逃していますか？

使い方Dispose()とデストラクタについて質問があります。いくつかの記事と MSDN のドキュメントを読むと、これが推奨される実装方法Dispose()とデストラクタのようです。

しかし、この実装について 2 つの質問があります。以下をお読みください。

GC.SupressFinalize(this) on Dispose()

プログラマーusingが Dispose() を明示的に使用または呼び出すと、クラスは を呼び出しGC.SupressFinalize(this)ます。ここでの私の質問は次のとおりです。

• これは正確には何を意味するのでしょうか? オブジェクトは収集されますが、デストラクタは呼び出されませんか? デストラクタはフレームワークによって Finalize() 呼び出しに変換されるため、答えはイエスだと思いますが、よくわかりません。

Dispose() 呼び出しなしでファイナライズする

GC がオブジェクトを消去しようとしているが、プログラマーが呼び出さなかったとします。Dispose()

• この時点でリソースを処分しませんか? つまり、なぜデストラクタでリソースを解放できないのでしょうか?

• if の内側と外側で実行する必要があるコードは何ですか?

  /li>

前もって感謝します

オブジェクトが GC.SuppressFinalize を呼び出したかどうかを検出する方法はありますか?

次のようなオブジェクトがあります (明確にするために完全な Dispose パターンは省略されています)。

ownsResourceコンストラクターのパラメーターがの場合false、ファイナライザーは何もする必要がありません。そのためGC.SuppressFinalize、コンストラクターから直接呼び出すのが妥当なようです (少し変わっている場合)。ただし、この動作は風変わりなので、XML doc コメントに書き留めておきたいと思います...コメントしたい場合は、単体テストを作成する必要があります。

しかし、System.GCにはオブジェクトのファイナライズ可能性を設定するメソッド( SuppressFinalize、ReRegisterForFinalize ) がありますが、オブジェクトのファイナライズ可能性を取得するメソッドはありません。Typemock を購入するか、独自の CLR ホストを作成する以外に、特定のインスタンスで GC.SuppressFinalize が呼び出されたかどうかを照会する方法はありますか?

これは私が確認するためだけのものです、私はこれを正しく理解しました：

IDisposalパターンを実装する大規模なリソースクラスがあります。これは、（設計上）複数回呼び出されるように実装する必要があります（もちろん、正確に1回呼び出そうとしても）。また、バックアップと同様に、Dispose（）メソッドも呼び出すファイナライザーを実装します。手動で呼び出された場合、Dispose（）はGC.SuppressFinalize（this）も呼び出します。

周りの処分パターンのいくつかの例があります。それらのほとんどは、破棄コードの最後でGC.SuppressFinalize（this）を呼び出します。クリーニングの前に、Dispose（）メソッドの先頭で呼び出す方がよいと主張する人もいます。後で主張しますが、これにより、クリーンアップ中にGCがファイナライザーを同時に呼び出さないことが確実になります。

質問：
GC.SuppressFinalizeを最初に配置しても、それ以上の効果はないようです。まだ競合状態がありますよね？では、代わりにスレッドセーフな方法でDispose（）を実装する必要があるというのは本当ですか？

私はファイナライザーを持つクラスを持っています。しかし、私は常に を呼び出しDispose()ており、Dispose()を呼び出しGC.SupressFinalize(this)ているため、オブジェクトが実際にファイナライズ キューに入ることは決してないと思います。ファイナライザーは、クラスの別のユーザーが呼び出しを忘れた場合のバックストップとしてそこにありますDispose()。

ファイナライザーが呼び出されず、オブジェクトがファイナライズキューに到達しない場合でも、ファイナライザーを実装するだけでパフォーマンスが低下することはありますか?

以前はそうではないと思っていましたが、 Bill Wagner による『 Effective C#: Second Edition 』の 102 ページには、「たとえ呼び出されなくても、ファイナライザーが存在すると、型のパフォーマンスが大幅に低下する」と書かれています。