私の理解では、キャッシングとは、データを便利な場所に保存して、すばやくアクセスできるようにすることです。キャッシングの各実装 (例: LinkedHashMap、MemcacheD ) はキー値ストアです。それは理にかなっています、私は同意します。しかし、私の質問は、デフォルトでキャッシュもキー値を意味しますか? つまり、オブジェクトの配列リストはキャッシュと見なされませんか? Entry<key, value>つまり、LRU キャッシュを実装する際に、データをオブジェクトにする必要がある場合はどうなりますか?
さらに説明が必要な質問や不完全なデータの提供などを防ぐために、3つの異なる質問で説明しました。
つまり、オブジェクトの配列リストはキャッシュと見なされませんか?
はい、キャッシュとして使用できます。配列インデックスはキャッシュキーです。
配列リストの問題は、通常、インデックスからオブジェクトへの提案ができないことです。つまり、インデックスは通常、マッピング先のデータの意味のある参照データではありません。
キャッシュがキー値ベースである理由を考える場合、キャッシュが解決する問題について考える必要があります。
キャッシュが解決する問題は次のとおりです。
簡単な参照データからすばやく取得するのに時間がかかるデータ構造にアクセスする方法は?
したがって、取得するのが難しいデータ構造の単なる参照先であるデータが常にいくつかあります。たとえば、顧客番号などです。-> お客様。これらの参照対象データは、キャッシュ キーと呼ばれます。これは、より複雑なデータ構造を作成または取得するのに十分な情報を備えた簡単なデータ構造です。したがって、これは単なるマッピングであるため、通常、キャッシュはマップ データ構造によって実装されます。
最初の質問に戻る
つまり、オブジェクトの配列リストはキャッシュと見なされませんか?
配列を使用することは、参照データが単なる整数であることを意味することがわかりました。そのため、配列リストのキャッシュは通常、未使用のスペースが多く断片化されています。顧客番号について考えてみましょう。→お客様事例。この例では、配列リストのサイズは少なくとも最大の顧客番号でなければなりません。それはキャッシュされ、より大きな顧客番号を持つ新しい顧客の場合に成長します。キャッシュする必要があります。
これを最適化したい場合は、完全な整数範囲を非常に小さい範囲にマップする方法を見つける必要があります。しかし、これを行うと、顧客番号が 2 つになる可能性があります。同じインデックスにマップされます。したがって、衝突が発生します。これを処理するには、リストまたは何らかのリンクされたデータ構造を使用して、すべてのオブジェクトをある位置に同じ値で保存する必要があります。
それがHashMap仕組みです。
特定の戦略を使用することではなく、キャッシュの目標がすべてだと思います。
キャッシュから期待されるもの - 適切なポインターはhttp://commons.apache.org/proper/commons-jcs/である可能性があります
キーと値のペアは、キャッシュを実装するための多くの一般的なアルゴリズム (apache one を含む) に簡単に適合するため、自然な候補になります。
しかし、キーと値のペアに基づいていない可能性がある他のアルゴリズムを使用しても問題はないと思います。その場合、キャッシュ スキームの新しい実装を最初から作成する必要がある場合があります。