2.2. エビクションストラテジー
各エビクションストラテジーには、以下に記載されているような特定の利点およびユースケースがあります。
ストラテジー名 | 操作 | 説明 |
---|---|---|
EvictionStrategy.NONE | エビクションは一切発生しません。 | これは、Red Hat JBoss Data Grid でのデフォルトのエビクションストラテジーです。 |
EvictionStrategy.LRU | LRU (Least Recently Used) 方式のエビクションストラテジーです。このストラテジーは、最も長い期間にわたって使用されてこなかったエントリーをエビクトします。これにより、定期的に再利用されるエントリーが確実にメモリーに残ります。 | |
EvictionStrategy.UNORDERED | 順序付けのないエビクションストラテジーです。このストラテジーは、順序付けのあるアルゴリズムを使用せずにエントリーをエビクトするため、後で必要になるエントリーをエビクトする可能性があります。しかし、このストラテジーでは、エビクションの前にアルゴリズムに関連する計算が不要であるため、リソースを節約します。 | テストを目的とする場合はこのストラテジーが推奨されますが、実際の作業の実装にあたっては推奨されません。 |
EvictionStrategy.LIRS | LIRS (Low Inter-Reference Recency Set) 方式のエビクションストラテジーです。 | LIRS は、さまざまな本番稼働ユースケースに適しているエビクションアルゴリズムです。 |
2.2.1. LRU エビクションアルゴリズムの制限
LRU (Least Recently Used) エビクションアルゴリズムでは、最も長い間使用されていないエントリーが最初にエビクトされます。キャッシュから最初にエビクトされるのは、最も長い間アクセスされていないエントリーです。ただし、LRU エビクションアルゴリズムは、アクセスローカリティーが弱い場合には最適に実行されないことがあります。この弱いアクセスローカリティーとは、キャッシュに入れられ、長い間アクセスされていないエントリーについて使用される技術用語であり、エントリーの置き換えは最も早くアクセスされる順番で行われます。このケースでは、次のような問題が発生する可能性があります。
- 1 回限りの使用のためにアクセスされるエントリーが時間内に置き換えられない。
- 最初にアクセスされるエントリーが不必要に置き換えられる。