問題タブ [finalize]

Javaにはfinalizeブロックがあり、ブロックが残った後にいくつかのステートメントを実行できます（例外が発生した場合でも実行されます）。例：

Adaには、 Finalize操作を実装できる制御されたオブジェクトがありますが、javaのようにfinalizeブロックに相当するものはありません。これは、ログ記録、ファイルのクローズ、トランザクションなどに役立ちます（可能なブロックごとに特定のタグ付きタイプを作成する必要はありません）。

1. （コードを読みやすくしながら）Ada 2005でそのようなfinalizeブロックをどのように実装しますか？
2. Ada 2012には、ファイナライズコードを簡単に実行できるようにする計画がありますか？

上記のコードでは、 finalize() は実行されません。コンソールには何も出力されません。gc() からコメントを削除すると、finalize() が実行され、「cleaned」がコンソールに出力されます。ガベージ コレクタを明示的に呼び出さなければならないのはなぜですか?

呼び出し元が到達できなくなったときにPOJOへの更新を保存できるORMスタイルのシステムを実装したいと思います。

参照クラスはそれを実行できると思いましたが、オブジェクトがクリアされた後にのみ参照をキューに入れるようです（収集できるようになったときだと思っていました）。したがって、キューに入れると、.get（）メソッドは常に返されます。ヌル。

ファイナライザーを使用することはできましたが、前回それらが疑わしいことを確認しました（すぐに実行される、またはまったく実行されるとは限りません）-ファイナライザーとrunShutdownHook（）の組み合わせは機能すると思いますが、それはかなり沼沢地になりつつあります。

義務的な「呼び出し元が完了したら.save（）を呼び出すだけ」以外に、私が考えていない別のパスはありますか？

サーバー上にある Oracle DB に対して実行される ac# 3.5 フレームワーク Windows アプリケーションがあります。

アプリケーションのフォームの 1 つには、上部に 8 つのタブがあります。各タブのタブ コンテンツ領域内にはコンボボックスがあります。コンボボックスには、各フォームに同じ情報が表示されます。ユーザーがドロップダウンまたはキーボードの矢印を使用してコンボボックスの値を変更すると、8 つのタブ付き領域に、Oracle から取得したデータが入力されます。

既存のプログラムの構造に基づいて、コンボボックスが変更されるたびに、約 20 の個々の DB 接続が開かれます。まず、さまざまなタブから正しいテーブルにデータを保存するために、約 8 つが呼び出されます。各タブの内容は、そのタブのデータを保存するために DB クラスに渡されます。次に、コンボボックスに基づいてテーブルからタブをロードするために、約 8 回の DB 呼び出しが行われます。

明確にするために、車のモデルを変更するタブでコンボボックスを選択するようなものです。各タブは、「インテリアオプション」「エンジンオプション」などのようなものになります。

次に、ID に基づいて高レベルのレコードをロックするために DB 呼び出しが 2 回行われ、他の誰もその特定のレコードを同時に編集できなくなります。

全体として、プロセスはかなり堅実です。セーブ/ロード時間は爆速です。ほぼ瞬時にデータを保存/読み込みして、2 つの異なるコンボボックスの値を切り替えることができます。

次に問題が発生します

十分な速さで前後にスピンすると (何人かのユーザーも同様に行っています)、プログラム全体がハングします。クラッシュすることはありません。ハングするだけです。

デバッグ環境でこれを繰り返すと、常に同じコード行で停止していることがわかりました (単純なレコードセットの割り当て (たとえば、CarModelInterior.Notes = Convert.ToString(myReader[6]);))。

その後、ガベージ コレクター (GC) スレッドがバックグラウンドで実行されていましたが、毎回同じ場所で停止していました。

RED-Gate メモリ/パフォーマンス モニターのインストールに入ります。

私が見つけたのは、コンボボックスの値を切り替える速度が速ければ速いほど、GC Finalizer キューがいっぱいになる速度が速かったことです。最終的に、同じ SQL 呼び出しがリストの一番上にあったようです。

私の仮定と当て推量を入力してください。

私の考えでは、開かれている接続が多すぎて十分な速度でファイナライズされていないか、どこかでロックが発生しています。

私が言えることは、プログラム全体のすべての DB 呼び出し (すべての異常な呼び出し) が "USING" ステートメントを使用しているため、すべての破棄が自動的に完了するということです。また、すべて（はい、アプリケーション全体をチェックしたように）、すべてのDB呼び出しはプライマリスレッドにあります。したがって、各コンボボックス値の変更に対して行われる 20 ほどの DB 呼び出しはすべて順番に行われます。これにより、少なくともシングルスレッドの問題である限り、ロックの可能性が排除されました。

私は何を残していますか？この時点で、私はあきらめてここに投稿したほどのグーグルです。ファイナライズ キューの処理速度が十分でない可能性はありますか? 他のアイデアはありますか？

オブジェクトをメモリから再利用するときに、例外が GC によって無視されるタイミングがよくわかりません。

finalize メソッドを使用している場合try/catch、常に実行されていることがわかります...では、例外がスローされないのはどのような場合ですか?

ありがとう。

ユーザーがオブジェクトを作成、編集、削除できる Silverlight アプリケーションに取り組んでいます。彼らが行った変更は、4 分ごとに処理されるキューに入れられます。更新が処理されると、非同期 Web メソッド呼び出しを介して送信され、一度に 1 つずつ SQL データベースに保存されます。最初の更新が終了すると、次の更新が開始されます。
ユーザーが変更を行い、4 分間のタイマーが切れる前にブラウザー アプリを終了すると、問題が発生します。現在、変更は失われつつあります。

私は、私が行った前にこれに取り組んでいた人に基づいて構築し、Dispose メソッドと Finalize メソッドを調べて、ファクトリがシャットダウンされているときに更新プロセスを開始しようとしましたが、Web サービス呼び出しの非同期の性質のために機能していません. 必要なオブジェクトが既に破棄されているというエラーが表示されます。

ユーザーがWebページを閉じたり更新したりしようとしたときに、webmethodを使用してupdatequeueにデータを保存する方法を探しています。キューが更新でいっぱいになるとは思っていません。これは通常、一度に数時間実行されるアプリケーションです。

Java の弱参照を理解するために、Java 言語仕様を調べる必要がありました。セクション 12.6 の次の部分は、私を困惑させます。

ファイナライズされていないオブジェクトでは、ファイナライザーが自動的に呼び出されたことはありません。ファイナライズされたオブジェクトのファイナライザーが自動的に呼び出されました。ファイナライズ可能なオブジェクトでは、ファイナライザーが自動的に呼び出されることはありませんが、Java 仮想マシンは最終的にそのファイナライザーを自動的に呼び出す可能性があります。

では、ファイナライズされていないオブジェクトとファイナライズ可能なオブジェクトの正式な違いは何ですか? 引用から、ファイナライズされていないオブジェクトとファイナライズ可能なオブジェクトが異なる場合、ファイナライズされていないオブジェクトの場合、JVM が最終的にそのファイナライザーを呼び出す可能性があるというのは事実ではないようです。少し混乱するか、まだ勉強する英語のセマンティクスがいくつかあります;)

Java 仕様のセクションへのリンク:ファイナライズの実装

次のような単純な Java クラスを作成しました。

コンテンツをバイト配列とファイル名として渡すと、クラスは TempFile をどこかに作成します。

}

ファイナライズメソッドでクリーンアップを実装すると、GC がオブジェクトを破棄するときに一時ファイルが自動的に削除されると思いました。

これをデバッグしてみましたが、ファイナライズメソッドが呼び出されていないようです。

どういう理由ですか？これは、これを Tomcat サーバーにデプロイしているためでしょうか?

乾杯

クラスインスタンスがガベージコレクターによって収集されるたびにfinalize（）が呼び出されることを私は知っています。ただし、クラスのインスタンスをキューを介して別のスレッドに渡すときは、少し混乱します。

これがThread1のスケルトンであるとしましょう。

次に、スレッド2はパケットをキューから削除し、長時間の操作を実行します。この2番目のスレッドはパケットの「コピー」を取得しますか、それとも何らかの参照によるものですか？重要なのは、コピーによる場合、スレッド1で作成されたインスタンスのfinalize（）は、スレッド2がパケットを処理する前に呼び出すことができるということです。参照による場合、finalize（）はパケット内の情報に対して1回だけ呼び出されることが保証されています。

この基本的な例は重要性を示していないかもしれませんが、オブジェクトを使い終わったときにメモリを破壊するために、（JNIからの）Cポインターをパケットに格納しています。コピーで渡された場合、2番目のスレッドが完了する前にメモリが破壊される可能性があります。参照によって渡された場合は、GCが両方のスレッドで使用されなくなったことを確認した後でのみ破棄する必要があります（私の望ましい動作）。この後者のシナリオが保証されていない場合は、finalize（）を使用せず、他の何かを使用しますが、より複雑になります。

Java/Android/JNI の長い話を簡単に言うと、Packet という名前で作成したオブジェクト/クラスと、私が作成した下位レベルの C コードへの JNI インターフェイスの 2 つのクラスがあります。あるクラスでは、着信パケットを解析して ArrayList に格納します。それらが「解析」されると、関数 Packet.dissect() が呼び出され、JNI を使用して下位レベルの C コードを呼び出します。この C コード malloc() の一部のメモリは、Packet オブジェクトのプライベート メンバーに格納する Java コードへのメモリ ポインタを返します。

ここで、リークが発生しないように、このメモリを確実に解放したいと考えています。したがって、Packet オブジェクトが使用されなくなったとガベージ コレクターが判断した場合は、finalize() を使用して JNI C コード関数を呼び出し、ポインターを渡してメモリを解放します。

2 番目のクラスとArrayListを共有しようとするまで、これは問題なく機能します。そのために、最初のクラスの ArrayList リストを含むブロードキャストを 2 番目のクラスの BroadcastReceiver に送信することで、Android で Broadcast を使用します。最初のクラスから放送される場所は次のとおりです。

これを行うことについて私が正しいと思ったのは、リスト内の各パケットがオブジェクトへの参照によって 2 番目のクラスに渡されるということです。これが真である場合、2 つのクラスが List とその中のオブジェクトをどのように処理しても、ガベージ コレクターは各パケットに対して 1 回だけ finalize() を呼び出すことが保証されます(両方のクラスが各パケットで終了したと見なされる場合)。 . これは非常に重要です。そうしないと、同じポインターに対して free() が 2 回呼び出されます (SEGFAULT が発生します)。

これは私に起こっているようです。2 番目のクラスがブロードキャストから ArrayList を受け取ると、それを解析し、リストからいくつかのパケットを保持します。そうするとき、パケット型のメンバーを持つ別のオブジェクト/クラスがあり、そのパケットが「気に入った」場合は、次のようにして保存します。

最終的に、ブロードキャストを受信したこのメソッドが戻り、一部のパケットが「保持」されました。最後に、ボタンをクリックすると (数秒後)、元のクラスの ArrayList がクリアされます。

ここで clear() が呼び出された場合でも、最初のクラスがパケットの一部を「保持」している場合、ガベージ コレクターはそれらに対して finalize() を呼び出さないと想定しています。これが false になる唯一の方法は、(1) ブロードキャストが送信されるときに ArrayList がコピーされ、参照によって渡されない場合、または (2) パケットが 2 番目のクラスである Packet オブジェクトに「保持」される場合です。参照によって保持されるのではなく、コピーされます。

free() が同じメモリの断片に対して 2 回呼び出されることがあるからです。私はそれが割り当てられていることを確認し（「新しい解剖：MEMORY_ADDRESS1 - IGNORE_THIS」）、同じメモリアドレスの割り当てを解除しようとして2つのfinalize（）が呼び出されます：

したがって、渡されるオブジェクトについて私が行っている 2 つの仮定のうちの 1 つは誤りです。メモリを適切にクリーンアップできるように、参照によってオブジェクトをより慎重に渡す方法を知っている人はいますか?

私の質問をここまで読んで理解していただけたなら、ありがとうございます ;)