問題タブ [soft-references]

WeakHashMapinがあることは知っていますが、これによってのみ参照されるすべてにsがjava.util使用されるため、参照されるオブジェクトは次のGCサイクルで失われます。したがって、ランダムなデータをキャッシュしたい場合はほとんど役に立ちません。ランダムなデータは、残りの時間はハードリンクされていなくても、再度要求される可能性が非常に高くなります。最善の解決策は、代わりにsを使用するマップですが、JavaRTパッケージで見つかりませんでした。WeakReferenceMapSoftReference

java.lang.ref.WeakReferenceとはどう違いjava.lang.ref.SoftReferenceますか？

私はWeakReferenceが大好きです。しかし、参照がどの程度弱いと見なすか (たとえば、1 から 5 のスケールで) を CLR に伝える方法があればいいのにと思います。それは素晴らしいことです。

JavaにはSoftReference、WeakReferenceがあり、「ファントム参照」と呼ばれる3番目のタイプもあると思います。これは、そのオブジェクトがチョップを取得するかどうかを決定するときに、GC が異なる動作アルゴリズムを持っている 3 つのレベルです。

.NET の WeakReference をサブクラス化して (幸いなことに、それは封印されていません)、有効期限タイマーなどに基づく疑似 SoftReference を作成することを考えています。

キャッシュされたオブジェクトへのソフト参照を持つキャッシュがあります。キャッシュされたオブジェクトがクリアされたときに何が起こるかについて、キャッシュを使用するクラスの動作の機能テストを作成しようとしています。

問題は、ソフト参照を確実にクリアできないように見えることです。大量のメモリを使い果たすだけではうまくいきません。ソフト参照がクリアされる前に OutOfMemory が発生します。

Javaにソフト参照をより積極的にクリアさせる方法はありますか?

ここにあります：

「ただし、OutOfMemoryError がスローされる前にすべての SoftReferences がクリアされることが保証されているため、理論的には OOME を引き起こすことはありません。」

つまり、上記のシナリオは、キャッシュされたオブジェクトのハード参照を保持しているクラスでどこかにメモリリークがあることを意味する必要がありますか?

私は に精通していますが、単に gc が実行されるたびに (Java の のように) ではなく、メモリが少ない場合にのみWeakReferenceクリアされる参照型を探しています。メモリに依存するキャッシュを実装する方法を探しています。SoftReference

JavaにsoftreferenceベースのLinkedHashMapはありますか? いいえの場合、おそらく再利用できるコードのスニペットを誰かが持っていますか? 正しく参照することを約束します。

ありがとう。

いくつかのテストを実行するために、SoftReferenceのオブジェクトのキャッシュに保存したオブジェクトの一部またはすべてが破棄されたときにアプリケーションがどのように動作するかを確認したいと思います。

これを行うために、キャッシュされたSoftReferenceオブジェクトに格納されている参照を手動でクリアしたいと思います-これらのオブジェクトのVM処理をシミュレートします-ただし、現在そのオブジェクトへの強い参照を持っているものが他にない場合に限ります（これは次の場合に当てはまります）。別のプロセスが最近、参照されたオブジェクトをキャッシュから取得しました）。

私のアプリケーションはシングルスレッドなので、このコードの実行中にキャッシュされたオブジェクトのソフト到達可能性が変化することを心配する必要はありません。これはまた、私が現在ロックメカニズムを持っていないことを意味します-もし持っていれば、オブジェクトが「使用されている」かどうか、したがって強く到達可能かどうかを判断するためにこれらを使用できた可能性がありますが、残念ながら私は必要ありませんそのようなロックの。

私が試した1つのアプローチは、ReferenceQueueに登録されているキャッシュに格納されているすべてのオブジェクトに追加のSoftReferenceを作成することです。そうすることで、キャッシュ内のソフトに到達可能なすべてのオブジェクトに追加のSoftReferenceがキューに追加されることを期待していました。そのため、キューをループして、それらのオブジェクトをキャッシュから削除するだけでした。ただし、GCは、ソフトリーチ可能なオブジェクトをそれぞれのキューに自由にエンキューしているようです。そのため、キャッシュ内のオブジェクトの反復処理が終了すると、キューに何かが追加される保証はありません。

私も見てきたことの1つは、値が非常に小さい-XX：SoftRefLRUPolicyMSPerMBJVMオプションです。賢明なメモリ割り当てを使用すると、ソフトに到達可能なオブジェクトがソフトに到達できる瞬間に、キャッシュからソフトに到達可能なオブジェクトがクリアされる可能性がありますが、キャッシュからソフトに到達可能なオブジェクトをクリアするリクエストを受け取るまで、アプリを正常に実行したいと思います。 。JVMオプションとして、アプリの実行中にこの値を変更できるとは思いません。

それで、オブジェクトがソフトにしか到達できない（したがってクリアできる）かどうかを私がどのように判断できるかについて誰かが何か考えを持っていますか？

編集：明確ではなかったかもしれないいくつかの追加のポイント：

• これらのソフト参照オブジェクトをクリアしたいときに、アプリはおそらく便利な作業を行うでしょう。ですから、GCにオブジェクトをクリアさせようとしないほうがいいと思います。
• どのソフトに到達可能なオブジェクトをクリアするかを選択できれば望ましいでしょう。
• アプリを正常に実行したい、つまり本番メモリ設定を使用したい。コードの設定を変更すると、本番環境の値にリセットできますが、問題ありません。

検索ハンドルオブジェクトを開いたままにしておくと、クエリキャッシュに役立つ検索ライブラリを使用しています。時間の経過とともに、キャッシュが肥大化する傾向があり（数百メガバイトで成長し続ける）、OOMが起動し始めました。このキャッシュの制限を強制したり、使用できるメモリの量を計画したりする方法はありません。そのため、 Xmxの制限を増やしましたが、これは問題の一時的な解決策にすぎません。

最終的に、私はこのオブジェクトをの指示対象にすることを考えていますjava.lang.ref.SoftReference。したがって、システムの空きメモリが不足すると、オブジェクトが解放され、オンデマンドで新しいオブジェクトが作成されます。これにより、新たに開始した後の速度がいくらか低下しますが、これはOOMを押すよりもはるかに優れた代替手段です。

SoftReferencesについて私が目にする唯一の問題は、指示対象を確定するためのクリーンな方法がないことです。私の場合、検索ハンドルを破棄する前に閉じる必要があります。そうしないと、システムでファイル記述子が不足する可能性があります。明らかに、このハンドルを別のオブジェクトにラップし、ファイナライザーを記述して（または、ReferenceQueue / PhantomReferenceにフックして）、手放すことができます。しかし、ねえ、この惑星のすべての記事は、ファイナライザーの使用、特にファイルハンドルを解放するためのファイナライザーの使用を推奨していません（たとえば、 Effective Java ed。II、27ページ）。

だから私は少し戸惑っています。これらのアドバイスをすべて慎重に無視して続行する必要があります。そうでなければ、他の実行可能な選択肢はありますか？前もって感謝します。

編集＃1：トムホーティンによって提案されたようにいくつかのコードをテストした後、以下のテキストが追加されました。私には、提案が機能していないか、何かが足りないように見えます。コードは次のとおりです。

上記のスニペットを-Xmx10m（上記のコードのように）SoftReferencesを使用して実行すると、大量のis null :(印刷が行われます。しかし、コードをMyReference（MyReferenceで2行のコメントを解除し、SoftReferenceでコメントアウトする）に置き換えると、常にOOMになります。

アドバイスから理解したように、内部にハードリファレンスがあるからといって、MyReferenceオブジェクトが当たるのを防ぐことはできませんReferenceQueueよね？

利用可能なRAMの割合を使用して、Javaでオブジェクトをキャッシュする必要があります。他の人がこの質問をしたことは承知していますが、どの回答も私の要件を満たしていません。

私の要件は次のとおりです。

• シンプルで軽量
• プレーンな HashMap よりも劇的に遅くない
• LRU、または LRU に近い削除ポリシーを使用する

LinkedHashMap を試してみましたが、要素の最大数を指定する必要があり、使用可能な RAM をいっぱいにするのに必要な要素の数がわかりません (サイズは大きく異なります)。

私の現在のアプローチは、Google コレクションの MapMaker を次のように使用することです。

これは、より多くの RAM が必要なときに要素を自動的に削除する必要があるため、魅力的に思えましたが、重大な問題があります。その動作は、利用可能なすべての RAM をいっぱいにすることであり、その時点で GC がスラッシングし始め、アプリ全体のパフォーマンスが劇的に低下します。

EHCache のようなものについて聞いたことがありますが、必要なものに対して非常に重いようで、アプリケーションにとって十分に高速かどうかはわかりません (ソリューションが HashMap よりも劇的に遅くなることはあり得ないことを思い出してください)。 .

Javaでのソフト参照のユースケースは何ですか？JVMをシャットダウンする前に重要な情報をダンプするのに十分なリソースを解放するために、JVMのメモリが不足したときに、重要でないアイテムをガベージコレクションすることは有用でしょうか？

それらはソフト参照と呼ばれていますか？それらはソフトであり、「ストレス下に置かれる」と壊れます。つまり、JVMのメモリが不足しています。弱参照とファントム参照は理解していますが、これらが必要になる場合は実際には理解していません。