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