13

クエリ データを短期的にキャッシュするための単純なインメモリ (およびインプロセス) キャッシュを探しています (ただし、要求/応答を超えた短期的な意味、つまりセッション境界)。EhCache はおそらく機能しますが、必要なものが 1 つ提供されていないように見えます: キャッシュされるオブジェクトの数を制限するのではなく、キャッシュされたデータによって消費されるメモリの量を (概算で) 制限します。

シリアル化なしで特定のオブジェクトの正確なメモリ使用量を把握するのは難しいことを理解しています（一般的には、その遅さが私の用途の目的を損なうため、これは避けたいと思います）。サイズの見積もりを自分で提供する必要があります。

だから：キャッシュされたオブジェクトの「重み」を定義して、キャッシュされるものの量を制限できる単純なオープンソースのJavaキャッシュはありますか？

編集 (2010 年 11 月): 価値のあるものとして、この問題に対処しようとするJava CacheMateと呼ばれる新しいプロジェクトがあり、他のいくつかの改善のアイデア (マルチレベルのインメモリ インプロセス キャッシング) があります。

4

8 に答える 8

3

私はPaulに同意します。これは、ソフト参照キャッシュを使用することで解決されることがよくありますが、エントリを希望よりも早く削除する可能性があります。通常受け入れられる解決策は、ソフトキャッシュに排出される通常のキャッシュを使用し、可能であればミス時にエントリを回復することです。このビクティムキャッシングアプローチは非常にうまく機能し、バーは低くなりますが、空きメモリが利用できる場合は追加のメリットがあります。

メモリサイズはJavaエージェントを有効にすることで決定でき、SizeOfユーティリティ（ http://sourceforge.net/projects/sizeof ）を使用すると使用法は非常に簡単です。私はこれをデバッグ目的でのみ使用しました。通常の使用に採用する前に、オーバーヘッドのベンチマークを行うことをお勧めします。

私のキャッシングライブラリでは、コアアルゴリズムが実装されたら、エバリュエーターをプラグインする機能を追加することを計画しています。このようにして、コレクションを値として格納できますが、すべてのコレクションサイズの合計によってキャッシュを制限します。キャッシュ内の値がOutOfMemoryExceptionsを引き起こすため、無制限のコレクションを見てきました。そのため、制御することは非常に便利です。

これが本当に必要な場合は、そうしないことをお勧めしますが、これをサポートするために現在の実装を強化することができます。あなたは私に電子メールを送ることができます、ben.manes-at-gmail.com。

于 2009-03-28T20:54:15.687 に答える
2

EhCache V2.5は現在、キャッシュのメモリサイズに基づいて上限を設定できるソリューションを提供しています。詳細については、EhCache2.5ドキュメントを確認してください

于 2011-11-13T19:19:32.067 に答える
2

LRU アルゴリズムを有効にして単純な LinkedHashMap を使用し、その中に SoftReference を含むすべてのデータを入れるのはどうですか... cache.out(key, new SoftReference(value)) など??

これにより、キャッシュが使用可能なメモリの量に制限されますが、プログラムの残りの部分が強制終了されることはありません。これは、Java がメモリの需要がある場合にソフト参照を削除するためです...すべてではありません..最も古いものが最初に...通常. 参照キューを実装に追加すると、ストール エントリ (キーのみ、値なし) をマップから削除することもできます。

これにより、エントリのサイズを計算して合計を追跡する必要がなくなります。

于 2009-03-30T00:03:47.407 に答える
0

測定が難しいだけでなく、定義も難しいのです。

2 つのキャッシュ エントリが同じ文字列を参照しているとします。キャッシュからいずれかを削除しても文字列がガベージ コレクションの対象にならないという事実にもかかわらず、両方ともその文字列のサイズをカウントしますか? 両方がキャッシュから削除された場合、文字列がコレクションの対象になる可能性があるという事実にもかかわらず、どちらもサイズをカウントしませんか? キャッシュにない別のオブジェクトがその文字列への参照を持っている場合はどうなるでしょうか?

興味のあるサイズを正確に記述できれば、プログラムで確認できるかもしれませんが、必要なものを正確に決定することさえ難しいと思うでしょう。

于 2009-03-27T17:58:46.210 に答える
0

オブジェクトのメモリ使用量を推測するだけでなく、合理的なアルゴリズムでは、オブジェクトを再作成するコストも推測する必要があります。妥当な推測としては、再作成のコストはメモリ サイズにほぼ比例します。したがって、要因は互いに打ち消し合い、どちらも必要ありません. 単純なアルゴリズムの方がうまくいくでしょう。

于 2009-03-27T18:09:54.607 に答える
0

キャッシュのメモリ使用量について意味のある尺度を定義することができます。: "retained size"を計算できます。残念ながら、保持サイズの計算はフル GC とほぼ同じくらいコストがかかるため、おそらくオプションではありません。特定の JVM 言語 (clojure?) では、キャッシュ内のオブジェクトが外部オブジェクトから参照されないことを理論的に確認してから、キャッシュの実際のサイズを監視できます。

于 2009-03-30T08:16:06.270 に答える
0

見積もりができない場合は、(システムからポーリングされた) JVM ヒープ サイズに基づいてフラッシュするか、(GC で) 孤立したオブジェクトからの finalize() 呼び出しによってトリガーされるキャッシュ エビクション ポリシーを記述します。

于 2009-03-27T18:33:35.017 に答える
-1

この仕事をするのは java.lang.ref.SoftReference です。通常、サブクラスにキーが含まれるように SoftReference クラスを拡張します。

于 2009-03-27T19:09:35.650 に答える