3.2. エビクションストラテジー

各エビクションストラテジーには、以下に記載されているような特定の利点およびユースケースがあります。

表3.1 エビクションストラテジー

ストラテジー名 操作 説明
EvictionStrategy.NONE エビクションは一切発生しません。 これは、Red Hat JBoss Data Grid でのデフォルトのエビクションストラテジーです。
EvictionStrategy.LRU LRU (Least Recently Used) 方式のエビクションストラテジーです。このストラテジーは、最も長い期間にわたって使用されてこなかったエントリーをエビクトします。これにより、定期的に再利用されるエントリーが確実にメモリーに残ります。  
EvictionStrategy.UNORDERED 順序付けのないエビクションストラテジーです。このストラテジーは、順序付けのあるアルゴリズムを使用せずにエントリーをエビクトするため、後で必要になるエントリーをエビクトする可能性があります。しかし、このストラテジーでは、エビクションの前にアルゴリズムに関連する計算が不要であるため、リソースを節約します。 テストを目的とする場合にはこのストラテジーが推奨されますが、実際の作業の実装にあたっては推奨されません。
EvictionStrategy.LIRS LIRS (Low Inter-Reference Recency Set) 方式のエビクションストラテジーです。 LIRS は、さまざまな本番稼働ユースケースに適しているエビクションアルゴリズムです。

3.2.1. LRU エビクションアルゴリズムの制限

LRU (Least Recently Used) エビクションアルゴリズムでは、最も長い間使用されていないエントリーが最初にエビクトされます。キャッシュから最初にエビクトされるのは、最も長い間アクセスされていないエントリーです。ただし、LRU エビクションアルゴリズムは、アクセスローカリティーが弱い場合には最適に実行されないことがあります。この弱いアクセスローカリティーとは、キャッシュに入れられ、長い間アクセスされていないエントリーについて使用される技術用語であり、この場合、最も早くアクセスされるエントリーは置き換えられます。このようなケースでは、次のような問題が発生する可能性があります。
  • 1 回限りの使用のためにアクセスされるエントリーが時間内に置き換えられない。
  • 最初にアクセスされるエントリーが不必要に置き換えられる。