2009-03-27 17 views
11

私はクエリデータの短期間のキャッシュ(しかし、リクエスト/レスポンスを超えた短期的な意味、つまりセッション境界)のための単純なインメモリ(およびインプロセス)キャッシュを探しています。 EhCacheはおそらく動作しますが、キャッシュされたオブジェクトの数に制限はありませんが、キャッシュされたデータで消費されるメモリの量には制限があります。インスタンス数だけでなく、メモリ内キャッシュのメモリ使用を制限するJavaキャッシュはありますか?

シリアル化なしでは、特定のオブジェクトの正確なメモリ使用量を把握することは難しいと私は理解しています(私の使用の目的が遅いため一般的な場合は避けたい)。サイズは自分自身を推定する。

So:キャッシュされたオブジェクトの量を制限するために、キャッシュされたオブジェクトの「ウェイト」を定義できる単純なオープンソースのJavaキャッシュがありますか?

EDIT(2010年11月):何が価値があるのは、他のいくつかの改善のアイデアと一緒に、この問題に取り組むためにしようとJava CacheMateと呼ばれる新しいプロジェクトがあるため(マルチレベルメモリ内のインプロセスキャッシュ)

+0

Hmmh。ほとんどの答えは私には問題のない部分に焦点を当てているので、私はひどく質問を書いたに違いない。私は有用な見積もりを提供することができます - 私はそれを利用するためにキャッシュが必要です。つまり、オブジェクトの数だけではなく、合計の重量です。私は '標準'のもののどれもこれをしないと思います。 – StaxMan

+1

私はあなたが必要とするもののもう少し詳細が役に立つと思います。アイテムの(静的な)重量を考慮に入れたい*唯一の要素ですか?おそらく、キャッシュがサポートできる合計「重量」が必要です。タイミングはどうですか?それはまったく有効なのでしょうか? –

+0

なぜサイズベースのキャッシュが必要なのか尋ねてもよいですか? – ReneS

答えて

3

これは、ソフト・リファレンス・キャッシュを使用することで解決されることが多いと私は思っています。通常容認できる解決策は、ソフトキャッシュに退去する通常のキャッシュを使用し、可能であればミスのエントリを回復することです。この犠牲者キャッシングのアプローチはかなり効果的ですが、自由なメモリが利用可能な場合には、より低いバーが得られますが、特別なメリットがあります。

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

私のキャッシングライブラリでは、コアアルゴリズムが実装されたら、評価者をプラグインする機能を追加する予定です。この方法でコレクションを値として保存できますが、キャッシュはすべてのコレクションサイズの合計でバインドされます。キャッシュ内の値がOutOfMemoryExceptionsを引き起こすため、無制限のコレクションを見てきました。そのため、制御が非常に便利です。

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

+0

これは実際にあなたがそれを追加すると動作するかもしれない何かのように聞こえる。 私が言ったように、私は正確な用法は必要ありません。バイト[]などのおおよそのコストを簡単に把握できます。私はちょうどウェイトを利用できるキャッシュを持つ必要があります。 – StaxMan

+1

私はこのことについてもっと話すことができるようにメールしてください。 LinkedHashMapをとても難しいことなく飾ることができると思います。そうすれば、構造全体を守るために巨大なロックを使用していないので、私が解決しなければならない競争懸念が解決されます。だから私は今この機能をオフにプッシュしたいと思います... –

0

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

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

あなたが興味を持っているサイズを正確に記述することができれば、プログラムでそれを確かめることが可能ですが、あなたが望むものを正確に決めることさえ難しいと思うでしょう。

+0

こんにちは、 コメントは全体的には意味がありますが、キャッシュのサイズ(保持サイズ)を計算するには意味のある方法があります。下の私の答えを見てください。 – kohlerm

+0

私は一般的なソリューションに興味がありません - 私の使用例では、はい、私は非常に簡単におおよそのサイズを決定することができます。 一般的なケースではもちろん不可能だと私は同意します。それはいいです、私はその問題を解決する必要はありません。 :) – StaxMan

+0

さて、サイズで重み付けをしてみたいです。前回の使用時の重み付けもしたいですか?どのようにそれらのバランスを取るようにしますか?前回の要素がなければ、HashMapの横にPriorityQueueを使用して、何を排除するかを検討することができます。あなたは退去する時を知っているので、合計を残してください。 –

0

オブジェクトのメモリ使用量を推測するだけでなく、合理的なアルゴリズムでは、オブジェクトを再作成するためのコストを推測する必要があります。合理的な推測では、レクリエーションのコストはメモリサイズにほぼ比例します。だから要因はお互いを取り消し、あなたはどちらも必要ない。単純なアルゴリズムがおそらくもっとうまくいくでしょう。

0

推論を行うことができない場合は、JVMヒープサイズ(Systemからポーリング)に基づいてフラッシュするか、孤立したオブジェクト(GC上)からfinalize()コールによってトリガーされるキャッシュエビクションポリシーを作成します。

+0

https://jira.jbossも参照してください。org/jira/browse/JBCACHE-11 –

-1

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

2

LRUアルゴリズムを有効にした単純なLinkedHashMapを使用し、すべてのデータにSoftReferenceを入れてみましょう。たとえば、cache.out(key、new SoftReference(value))?

これは、キャッシュが使用可能なメモリの量に制限されますが、メモリ要求があるときにJavaがソフト参照を削除するため、残りのプログラムを強制終了しません。 。インプリメンテーションに参照キューを追加する場合は、ストールエントリ(キーのみ、値なし)をマップから削除することもできます。

これにより、エントリのサイズを計算し、合計を記録することがなくなります。

+1

キャッシュ実装にはSoftreferncesを使用することは本当に良い考えではありません。少なくともアプリケーションサーバーにはありません。その理由は、彼らがどれくらい長く生きているかを本当に制御できないからです。 – kohlerm

+0

さて、あなたのニーズによって異なります。通常、キャッシュは限られた予測可能性しか必要としません。メモリが不足している場合の緊急値に基づくLRUアルゴリズムはそれほど悪くありません。 2つのレベルのキャッシュを使用して改善することができます。 – ReneS

+0

ポイントは、Softreferencesのライブタイムはアプリサーバーの空きメモリにのみ依存するということです。アプリケーションごとに独立して制御することはできません。 – kohlerm

0

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

+0

しかし、この尺度では、キャッシュから2つのエントリのいずれかを押すと空き領域がほとんどなくなる可能性があることを考慮していませんが、*両方を押し出すと非常に大きな量が解放される可能性があります。 –

+0

こんにちは、Jon、 キャッシュ全体の「保持セット」を計算するだけで済みます。キャッシュの "ルート"オブジェクトをシミュレートし(今はそれを仮定します)、メモリから削除して、シミュレートされた完全なGCを実行してから、どのオブジェクトを再利用するかを数えます。 – kohlerm

1

現在、EhCache V2.5は、キャッシュのメモリサイズに基づいて上限を設定できるソリューションを提供しています。詳細はこちらチェックアウトEhCache 2.5 Documentation

+0

ええ、私はそれを見ました、それは便利な追加です。 – StaxMan

関連する問題