問題タブ [finalization]

オブジェクトが Finalize メソッドを実装しているが、その内部でアプリケーションの有効な静的オブジェクトを参照しているとします (設計は悪いですが、非常に可能性があります)。

ここで、GC が開始され、オブジェクトをファイナライズ キューに入れてファイナライズし、FReachable キューに移動してファイナライズ メソッドを呼び出します。

しかし、おっ！生きているオブジェクトを参照していることがわかるため、GC がオブジェクトによって占有されているメモリを再利用できず、オブジェクトが再び生きているとマークされます。ゾンビのオブジェ！

この時点で、このオブジェクトはどこにありますか?

1. Freachable のままですか？
2. ファイナライズ キューに残っていますか?
3. 不確定な状態でマネージド ヒープに残る (freachable およびファイナライズ キューから削除される)?

また、そのようなオブジェクトの ReRegisterForFinalize() に最適な場所は何ですか?

OleVariantにカプセル化されたインターフェースをリリースするための安全で決定論的な方法を見つけようとしています。

AFAICS Delphiは、プロシージャの最後にインターフェイス参照をリリースしますが、私の場合は、COMをシャットダウンする必要があるため、以前にリリースする必要があります。

私は、OleVariantを、呼び出す前に解放できる追加のクラスインスタンスに配置することを考えましたCoUninitialize。

この解決策は安全ですか、それとも私が見落としていたより良い解決策がありますか？

どうやら、制約付き実行領域の保証はイテレーターには適用されません（おそらく、それらがどのように実装されているかなどが原因です）が、これはバグですか、それとも設計によるものですか？[以下の例を参照してください。]

つまり、イテレータで使用されるCERのルールは何ですか？

（コードは主にここから盗まれました。）

静的にリンクされたランタイムパッケージと、それらを使用するデザインタイムパッケージを使用するアプリケーションがあります。何らかの理由で、ユニットファイナライズセクションのコードが実行時に実行されていません（これがいつ発生し始めたかはわかりません）。

Delphiをシャットダウンするとメッセージが表示されますが、アプリケーションがシャットダウンしたときは表示されません。ShowMessageにブレークポイントを設定すると、そこでブレークしますが、行は実行されないという点で、さらに奇妙になります。ファイナライズに複数の行がある場合、デバッガーは最初の行で停止し、実行せずに最後にジャンプします。

ProcOneブレークポイントのコールスタックは、@ Halt0 => FinalizeUnits=>MyPackage.MyUnit.Finalizationを示しています。

パッケージを使用しないアプリケーションにユニットを含めると、すべてが正しく実行されます。

誰かがこれを引き起こしている可能性がある考えを持っていますか？

編集：

正しい方向を指しているアレンバウアーのコメントのおかげで、私は問題を切り分けることができました。アプリケーションがランタイムパッケージでビルドされ、そのパッケージとユニットを参照する別のパッケージを動的にロードすると、問題が発生するようです。

問題を実証するテストプロジェクトを作成しました：TestFinalization

誰かがこれの理由および/または回避策を知っていますか？通常、外部リソースがクリーンアップされていないことに気付くまで、ファイナライズが実行されていないことに気付かない場合があります。

データベースが破損しているという SQLITE_CORRUPT エラーを受け取りました。

私のコードには、ステートメントを常に sqlite3_finalize しようとする try/finally 句があります。

どうやら破損したデータベースでステートメントをファイナライズしようとすると、再び SQLITE_CORRUPT が発生します。

質問: データベースが破損していると報告された場合、ステートメントを確定する必要がありますか?

Dispose最近、同僚と の値と を実装する型について話し合っていましたIDisposable。

クリーンアップするアンマネージ リソースがなくてもIDisposable、できるだけ早くクリーンアップする必要がある型に対して実装する価値があると思います。

私の同僚は別の考え方をしています。IDisposableあなたのタイプは最終的にガベージコレクションされるため、管理されていないリソースがない場合は実装する必要はありません。

私の主張は、できるだけ早く閉じたい ADO.NET 接続があれば、IDisposableandを実装するのusing new MyThingWithAConnection()が理にかなっているというものでした。私の同僚は、裏では ADO.NET 接続は管理されていないリソースであると答えました。彼の返答に対する私の返答は、最終的にはすべてが管理されていないリソースであるというものでした。

が呼び出された場合はマネージド リソースとアンマネージド リソースを解放するが、ファイナライザー/デストラクタ経由で呼び出された場合はアンマネージド リソースのみを解放する、推奨される破棄可能なパターンを認識しています(また、IDisposable 型の不適切な使用を消費者に警告する方法について少し前にブログを書きました) 。Dispose

それで、私の質問は、管理されていないリソースを含まないタイプを持っている場合、それを実装する価値はありIDisposableますか?

私のアプリケーションには、次のレコードがあります。

そして、私はこの配列でこのレコードを使用しています:

実行時に配列をロードしたままにしていますが、特定の時点ですべてのデータをクリアして新しいデータを追加する必要があります。

使用するだけで十分ですか:

または、何かを確定する必要がありますか?

多くのフォームを持つマルチスレッド アプリケーションを使用していますが、フォームを作成する前にいくつかのクラスをインスタンス化し、いくつかの初期化を呼び出す必要があります。もちろん、対応するファイナライズ コードを実行する必要があります。

.dpr ファイルの簡単な例を次に示します。

ここでの問題は、ブロック内のコードがフォームの/のfinally前に実行されることです。unitのセクションを見ると、これは明らかです。OnDestroydestructorfinalizationForm

そして、所有しているすべてのフォームを効果的に解放するDoneApplication呼び出し。Application.DestroyComponentsApplication

したがって、で作成されたフォームは、メインブロックApplication.CreateForm内のコードの後で破棄されます。begin..end

私が望むのは、Application.Runすべてのフォームが破棄された後、それらのOnDestroyイベント ハンドラーがConfig、DLL で定義されたオブジェクトと外部関数を認識できるようにすることです。例外が発生した場合も同様です。しかし、標準のアプリケーションの例外処理 ifConfig.FreeまたはUnlodDllsraise も必要です (アプリケーションはまだ存在している必要があります)。

ご了承ください：

• コードをより明確にしてデバッグ可能に保つために、ブロックを使用しないfinalizationことをお勧めします (.dpr で可能でしょうか?)。
• 今のところ、あまり多くのコードを変更したくない (例: 動的にフォームを作成する)

Application.DestroyComponents最も簡単な解決策は、 afterを明示的に呼び出すことだと思いますApplication.Run。デメリットはあると思いますか？よりエレガントなソリューションはありますか？

ありがとうございました