問題タブ [finalizer]

単体テストと統合テストのプロファイリングを行っていますが、NHibernate.Transaction.AdoTransaction のファイナライザーに多くの時間が費やされていることがわかりました。これは、適切に破棄されていないことを意味します。

コードで直接 AdoTransaction を使用していないため、NHibernate 内の他のオブジェクトで使用されている可能性があります。私が何を処分するのを忘れているのか分かりますか?

これが私のテキストフィクスチャです：

私は自分の理解IDisposableが正しいことを確認しようとしていますが、まだよくわからないことがあります。

IDisposable2つの目的を果たしているようです。

1. 管理対象オブジェクトをオンデマンドで「シャットダウン」するための規則を提供するため。
2. 管理対象オブジェクトが保持する「管理対象外のリソース」を解放するための規則を提供するため。

私の混乱は、どのシナリオで「管理されていないリソース」が機能しているのかを特定することから来ています。

Microsoftが提供するIDisposable実装（管理）クラス（たとえば、データベースまたはソケット関連）を使用しているとします。

1. 上記の1IDisposableつだけで実装されているのか1＆2で実装されているのかをどうやって知ることができますか？
2. 内部に保持されているかどうかわからない管理されていないリソースが解放されるようにする責任はありますか？instanceOfMsSuppliedClass.Dispose（）を呼び出す独自のクラスにファイナライザー（それは正しいメカニズムでしょうか？）を追加する必要がありますか？

このクラスについての私の理解では、クラスのファイナライザー (デストラクタ) が呼び出されることを確認したいときに使用する必要がありますが、私が行ったいくつかのテストから、そうではないようです。dispose メソッドが呼び出されていることを確認できない場合、他の方法はありますか? たとえば、タスク マネージャーなどでプログラムを閉じても、オブジェクトを終了するために何らかのコードが実行されるようにしたい場合はどうすればよいでしょうか?

メモリをリークしているように見えるWindowsFormsアプリがあるので、RedgateのANTSメモリプロファイラーを使用して、疑わしいオブジェクトを調べ、それらがすでにFinalizerキューにあるオブジェクトによってのみ保持されていることを確認しました。素晴らしい、まさにファイナライザーキューとは何ですか？最良の定義を教えていただけますか？逸話的なアドバイスを教えてください。

また、ファイナライザキューのすべてのルートGCオブジェクトは、「caller」という名前のSystem.Windows.Forms.Control+ThreadMethodEntryオブジェクトのインスタンスです。マルチスレッドUIの相互作用に関与しているように見えますが、それ以上のことはよくわかりません。私の明らかな怠惰と認められた無知を許してください、しかしこれらのリソースはすべてベンダーのコンポーネントの中に埋もれています。私はこれらの問題についてベンダーと話し合っていますが、会話をスピードアップするために何らかの方向性が必要です。ThreadMethodEntryの最も有用な定義も教えていただけますか？逸話的なアドバイスはありますか？

また、ファイナライザーキューにあるこれらのオブジェクトについても心配する必要がありますか？

更新：このRedGateの記事は役に立ちました。

次のコードで上記のエラーを取得します。それを修正する方法。ありがとう。探してください

以下のコードで。

私はボイラープレート コードのファンではありません。コピーして貼り付けて再利用すると、エラーが発生しやすくなります。コード スニペットやスマート テンプレートを使用したとしても、他の開発者が正しく行ったという保証はありません。そして、コードを見る必要がある場合は、それを理解したり、維持したりする必要があります。

コミュニティから知りたいのは、クラス階層のIDisposeの実装は、 「従来の」破棄パターンの正当な代替手段ですか? 正当とは、正しく、適度にパフォーマンスが高く、堅牢で、保守可能であることを意味します。

この代替案が明らかに間違っていても問題ありませんが、そうである場合は、その理由を知りたいです。

この実装は、クラス階層を完全に制御できることを前提としています。そうしないと、定型コードに頼らざるを得なくなるでしょう。Add*()の呼び出しは通常、コンストラクターで行われます。

これは、ファイナライズ (ほとんどの実装ではファイナライザーが必要ないことを知っている)、オブジェクトが破棄されているかどうかのチェックなどのサポートを提供するという意味で、「完全な」実装です。たとえば、実際の実装では、ファイナライザーを削除したり、ファイナライザーを含むDisposableObjectのサブクラス。基本的に、この質問のためだけに考えられるすべてを投入しました。

おそらく、私が見逃したエッジケースや難解な状況がいくつかあるので、このアプローチに穴を開けるか、修正して補強するために誰かを招待します.

他の方法として、DisposableObject で 2 つのリストの代わりに単一の Queue<Disposer> ディスポーザーを使用することもできます。この場合、ディスポーザーが呼び出されると、リストから削除されます。他にも考えられるわずかなバリエーションがありますが、一般的な結果は同じで、ボイラープレート コードはありません。

先日この記事を読んでいて、なぜ Dispose メソッドと一緒にファイナライザーがあるのか​​疑問に思っていました。Dispose を Finalizer に追加する理由については、SOを読んでください。私の好奇心は、ファイナライザーが Dispose メソッド自体で呼び出されるのはいつですか? コード例はありますか、それともソフトウェアが実行されているシステムで起こっていることに基づいていますか? もしそうなら、GC によって Dispose メソッドが実行されないとどうなるでしょうか。

変数が.Net言語でスコープを失うとすぐにファイナライズ/デストラクタコードを「自動的に」実行する方法はありますか? ガベージ コレクターは不確定な時間に実行されるため、変数がスコープを失うとすぐにデストラクタ コードが実行されないように思えます。IDisposable から継承し、オブジェクトで Dispose を明示的に呼び出すことができることはわかっていますが、非 .Net C++ がオブジェクトの破棄を処理する方法と同様に、より手間のかからない解決策があることを望んでいました。

望ましい動作 (C#):

あまり望ましくない:

私は DataGridView にデータ バインド オブジェクトを介して定期的に値を設定していますが、「ログ サイクル」中に行数が数千になる可能性があります。

新しい「ログ サイクル」が始まると、基になるデータ ソースがクリアされ、プロセスが再び開始されるため、グリッドがクリアされます。

これで問題ありませんが、前回の実行には時間がかかるため、以前の行はすべて第 2 世代のオブジェクトになり、完全な GC でガベージ コレクションのみが行われました。

ただし、最初の GC はそれらすべてをファイナライザー キューに送信するため、それらをクリアするには 2 回のフル GC が必要です。これは、2 倍の長さのメモリを占有することを意味します。

リフレクターを使用すると、DataGridViewRow にはファイナライザー メソッドがないことがわかりますが、DataGridViewBand オブジェクトから継承されます。これは、パブリック Dispose() メソッドを介して GC.SuppressFinalize(this) を呼び出します。

私の質問は、なぜ私の DataGridViewRows が最初のフル GC で収集されず、別の GC を待っているファイナライザー キューに入れられないのですか?

(ここでの私の仮定は、ファイナライザーのないオブジェクトはファイナライザー キューに配置されるべきではなく、ファイナライザーを持っているが GC.SuppressFinalize を呼び出すオブジェクトもキューに配置されないということです。この仮定は正しいですか?)

ありがとう。

私はWPFに比較的慣れていないので、WPFに関するいくつかのことは私にとってまったく異質です。1つは、Windowsフォームとは異なり、WPFコントロール階層はIDisposableをサポートしていません。Windowsフォームでは、ユーザーコントロールが管理対象リソースを使用している場合、すべてのコントロールが実装しているDisposeメソッドをオーバーライドすることで、リソースを非常に簡単にクリーンアップできました。

WPFでは、話はそれほど単純ではありません。私はこれを数時間検索し、2つの基本的なテーマに遭遇しました。

最初のテーマは、WPFコントロールに管理されていないリソースがないため、WPFはIDisposableを実装しないことを明確に述べているMicrosoftです。それは事実かもしれませんが、WPFクラス階層へのユーザー拡張が実際に管理対象リソースを（モデルを介して直接的または間接的に）使用する可能性があるという事実を完全に見逃しているようです。IDisposableを実装しないことにより、Microsoftは、カスタムWPFコントロールまたはウィンドウによって使用される管理されていないリソースをクリーンアップできる唯一の保証されたメカニズムを効果的に削除しました。

次に、Dispatcher.ShutdownStartedへの参照がいくつか見つかりました。ShutdownStartedイベントを使用しようとしましたが、すべてのコントロールで起動するわけではないようです。ShutdownStartedのハンドラーを実装したWPFUserControlがたくさんありますが、呼び出されることはありません。Windowsでのみ機能するのか、それともWPFAppクラスでのみ機能するのかわかりません。ただし、正しく起動されておらず、アプリを閉じるたびに開いているPerformanceCounterオブジェクトがリークしています。

Dispatcher.ShutdownStartedイベントよりも、管理されていないリソースをクリーンアップするためのより良い代替手段はありますか？Disposeが呼び出されるようにIDisposableを実装するためのトリックはありますか？可能な限り、ファイナライザーの使用は避けたいと思います。