التخزين المؤقت داخل الذاكرة وضبط Caffeine

Caffeine is a high-performance, near-optimal Java caching library and the default in-memory cache for Spring Boot when it is on the classpath.

• It uses the Window TinyLFU eviction policy, which beats plain LRU on real-world hit rates.
• It supports size-based, time-based, and reference-based eviction.
• It is fully concurrent and lock-free on the read path, ideal for high-throughput services.

In this lesson you will tune Caffeine's eviction, expiry, and size policies so a local cache stays fast without exhausting heap.

Spring Boot auto-configures Caffeine when both spring-boot-starter-cache and the caffeine dependency are present.

Then enable caching with @EnableCaching on a configuration class. Methods annotated with @Cacheable will use the Caffeine-backed CacheManager.

The most common policy for a local cache is bounded size. Use maximumSize to cap the number of entries; Caffeine evicts the least valuable entries (Window TinyLFU) once the bound is exceeded.

• Pick a size that fits comfortably in heap given your value object footprint.
• Eviction is not immediate at the boundary; it happens promptly but asynchronously.

When entries vary wildly in size, bound the cache by weight instead of count. Provide a maximumWeight and a Weigher that returns each entry's cost.

• You cannot combine maximumSize and maximumWeight on the same cache.
• Weights are computed once at insertion and are not updated afterward.

Time-based expiry comes in two flavors:

• expireAfterWrite: entry expires a fixed duration after it was created or last replaced. Best for data with a known freshness window (e.g. a price valid for 5 minutes).
• expireAfterAccess: entry expires a duration after its last read or write. Best for keeping hot data alive and dropping idle entries.

You may combine both; the entry expires when either condition fires first.

For a single shared spec, Spring Boot lets you skip Java config and use the spring.cache.caffeine.spec property. It accepts the comma-separated Caffeine spec string.

This is convenient but applies the same spec to every cache name; per-cache tuning still requires a programmatic CaffeineCacheManager or a custom CacheLoader.

refreshAfterWrite differs from expiry: instead of removing the entry, it asynchronously reloads it after the duration while still serving the old value. This avoids a latency spike on the first request after staleness.

• It requires a LoadingCache (a cache built with a CacheLoader).
• Only one thread triggers the refresh; others keep reading the existing value.
• Combine with a longer expireAfterWrite as a hard ceiling.

Here is a complete, framework-free program demonstrating maximumSize eviction. Insert more entries than the bound and observe that the cache never exceeds its size after cleanup.

This is the kind of micro-benchmark you can run to validate a tuning choice before wiring it into Spring.

Real services need different policies per cache: a tiny hot lookup table vs a large warm dataset. Subclass or configure CaffeineCacheManager so each name gets its own builder.

One clean approach is registering individual native caches by name on the manager.

You cannot tune what you do not measure. Enable recordStats() to expose CacheStats: hit count, miss count, eviction count, and average load penalty.

• A low hit rate suggests the cache is too small or the keys too cardinal.
• High eviction with high miss rate means maximumSize is starving the working set.
• Spring Boot's Micrometer integration publishes these as metrics when stats are on.

A few traps to watch for under high throughput:

• Unbounded caches: never build a cache without a size or expiry bound, or you risk an OutOfMemoryError.
• initialCapacity: set it near the expected steady-state size to avoid resize churn on the read-heavy path.
• Soft/weak references: softValues() ties eviction to GC pressure, which is unpredictable; prefer explicit size/time bounds for latency-sensitive caches.
• refreshAfterWrite without a loader: it silently has no effect on a manual cache.

You tuned Caffeine for high-throughput local caching in Spring Boot 4:

• Size: maximumSize for uniform entries, maximumWeight + Weigher for variable cost.
• Time: expireAfterWrite for freshness contracts, expireAfterAccess to keep hot data, combine for both ceilings.
• Refresh: refreshAfterWrite on a LoadingCache for stale-while-revalidate without latency spikes.
• Config: spring.cache.caffeine.spec for one shared spec, or registerCustomCache for per-cache tuning.
• Measure: always enable recordStats() and watch hit rate and eviction count to guide further tuning.