Why Caffeine Is the High‑Performance Local Cache Framework You Need

1. Overview

Caffeine is a high‑performance, high‑hit‑rate, low‑memory local cache library for Java, positioned as an optimized successor to Guava Cache. Spring 5 plans to drop Guava Cache in favor of Caffeine, and benchmark data (referenced in Caffeine’s Benchmarks [3]) shows Caffeine outperforming several other cache tools in both read and write scenarios.

2. Common Cache Properties

Typical cache creation uses

Cache<Object, Object> cache = Caffeine.newBuilder()…build();

with fluent configuration methods: initialCapacity: integer indicating expected number of entries to avoid repeated resizing. maximumSize: maximum number of entries; exceeding this triggers an asynchronous eviction thread. maximumWeight and weigher: total weight limit; eviction occurs when summed weights exceed the limit.

Expiration policies: expireAfterAccess: evicts entries after a period of inactivity (read or write). expireAfterWrite: evicts entries a fixed time after the last write. refreshAfterWrite: triggers asynchronous refresh via LoadingCache.refresh(K) or a custom CacheLoader.reload.

Reference‑type handling: .weakKeys(), .weakValues(), .softValues() for GC‑aware eviction. removalListener: receives a RemovalListener callback with key, value, and RemovalCause (EXPLICIT, REPLACED, EXPIRED, SIZE, COLLECTED) when an entry is removed. recordStats(): enables a CacheStats object that reports metrics such as hitCount, missCount, loadSuccessCount, evictionCount, etc.

3. Data Loading

Caffeine reuses Guava’s core concepts ( Cache, LoadingCache, CacheLoader, CacheBuilder) so migration is seamless. Manual cache usage includes put, getIfPresent, invalidate, and statistics retrieval. LoadingCache automates miss handling by associating a CacheLoader that computes values on demand or in bulk via loadAll. Example code demonstrates a LoadingCache with expireAfterWrite and a custom CacheLoader that simulates an expensive DB query.

4. High‑Performance Design

The key to Caffeine’s performance is its eviction algorithm, W‑TinyLFU, which combines the simplicity of LRU with the frequency awareness of LFU. The article explains why plain LRU suffers from cache pollution during full‑scan workloads and why LFU incurs high update overhead and struggles with bursty sparse traffic. TinyLFU mitigates these issues by using a Count‑Min Sketch to approximate frequencies and a “freshness” mechanism that lets new entries compete with older ones, evicting the less useful.

References to an external article on TinyLFU are provided for readers who want deeper implementation details.