Caching with @Cacheable

Spring's caching abstraction lets a single annotation — @Cacheable — remember an expensive method's result, while @CacheEvict keeps it fresh and providers like Caffeine or Redis do the storing.

Learn Caching with @Cacheable in our free Java course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick reference.

Part of the free Java course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

Before You Start

You should understand Spring beans and services , and be comfortable with maps and lambdas for the memoization demos.

What You'll Learn

The Big Idea — A Sticky Note on Your Monitor

💡 Analogy: Imagine someone keeps asking you for the office Wi-Fi password. The first time you walk to IT and fetch it (the expensive call); then you scribble it on a sticky note on your monitor. Every later request is answered instantly from the note — that's @Cacheable . But when IT changes the password, the note is now wrong , so you must tear it down and write the new one: that's @CacheEvict . The note can live on your own desk ( Caffeine , fast but only yours) or on a shared whiteboard everyone can see ( Redis , slower to reach but shared by the whole team).

Fetch the slow answer once, reuse it cheaply — and remember to update the note when the truth changes.

1️⃣ The Core — Remember Results by Key

@Cacheable is memoization: store a method's result keyed by its arguments so the expensive work happens once per key. The plain-Java demo uses computeIfAbsent to make that mechanism explicit.

2️⃣ Staying Correct — Eviction

A cache speeds reads but can go stale . When the source data changes you must remove the old entry — that's @CacheEvict . Forget it and readers keep seeing the outdated value.

3️⃣ The Spring Way — @EnableCaching + Annotations

Turn caching on once with @EnableCaching , then annotate methods: @Cacheable to read-through, @CacheEvict to invalidate, @CachePut to refresh. Spring applies the logic via AOP proxies.

4️⃣ Choosing a Provider — Caffeine vs Redis

Spring caches against whatever provider is on the classpath. Caffeine is a fast in-process cache for a single instance; Redis is a distributed cache shared across instances and surviving restarts.

🧠 Quick Recall

Answer: no — it's a cache hit, so the stored value is returned and the body is skipped.

Answer: @CacheEvict (or @CachePut ) on the write removes/refreshes the affected entry.

Answer: Redis — a distributed cache. Caffeine is local to a single JVM.

🎯 YOUR TURN — Memoized Fibonacci

Complete fib(n) using the cache map so each n is computed only once.

🧩 MINI-CHALLENGE — Read-Through Cache with Eviction

Implement get (cache-through) and set (update + evict) and prove the read after a set is fresh.

Common Errors

• ❌ Forgetting @EnableCaching. The annotations do nothing. Fix: add it to a config class.
• ❌ Not evicting on update. Readers see stale data. Fix: add @CacheEvict / @CachePut on writes.
• ❌ Self-invocation calls. Calling a cached method from within the same bean bypasses the proxy. Fix: call via the injected bean.
• ❌ Wrong key. Too coarse a key returns wrong results for different inputs. Fix: use a precise SpEL key.
• ❌ Unbounded cache. Memory grows forever. Fix: set a maximum size and TTL.
• ❌ Caching cheap or volatile methods. No benefit, added risk. Fix: cache expensive, stable, repeated calls.

Pro Tips

• 💡 Set a TTL and max size (e.g. Caffeine's expireAfterWrite , maximumSize ) to bound memory and staleness.
• 💡 Pick keys deliberately with SpEL, e.g. key = "#book.isbn" , to avoid collisions.
• 💡 Use Redis when you scale out so every instance shares one consistent cache.
• 💡 Measure first: cache the genuinely hot, expensive paths shown by your metrics — not everything.

📋 Quick Reference

Concept

Syntax / idea

Note

enable

@EnableCaching

On a config class

read-through

@Cacheable("books")

Skip body on hit

key

key = "#book.isbn"

SpEL, default = args

invalidate

@CacheEvict

Remove stale entry

refresh

@CachePut

Run + update cache

clear all

@CacheEvict(allEntries=true)

Whole cache

in-process

Caffeine

Fast, single node

distributed

Redis

Shared, survives restart

mechanism

AOP proxy

Intercepts the call

risk

stale data

Evict + TTL

📚 Resources / Keep Learning

• 📘 Cache Abstraction — Spring Framework reference
• 📗 Caching — Spring Boot reference
• 📗 Caffeine cache — project wiki

❓ Frequently Asked Questions

🎉 Lesson Complete!

You now understand how @Cacheable memoizes results by key, how keys are derived, how @CacheEvict and @CachePut keep data fresh, how @EnableCaching turns it all on, and when to choose Caffeine versus Redis.

Next up: Containerizing a Spring Boot App — Dockerfiles, layered jars, and buildpacks.

Practice quiz

Continue this course

• Previous: Monitoring with Actuator
• Next: Containerizing a Spring Boot App

Related lessons

• beans and services
• maps
• lambdas