缓存，看似简单，其实一旦用起来就会遇到各种 “暗礁”，比如缓存失效策略的细节、分布式架构下的数据一致性、内存占用暴涨等让人头疼的问题，很多人都是踩了坑才意识到缓存知识可不止于 “存取值” 那么浅。
本文聚焦于 Java 领域最受欢迎的两大缓存方案：本地缓存的 Caffeine，以及分布式缓存的 Redis。我们将分别讲讲这两款工具该在什么场景使用、怎样实现更加优雅高效的缓存策略，以及如何提前避开那些让你熬夜加班的典型陷阱。
缓存的目的
在深入实现之前，让我们先明确要解决什么问题。缓存的目的是：
- 减少数据库负载 —— 停止用相同的查询不断轰炸你的数据库。想象一下，你的数据库就像一家餐厅的服务员，如果每个客人都点同一道菜，服务员就得一遍遍跑厨房。有了缓存，就像给服务员配了个小本本，记住最近点过的菜，直接就能告诉客人，不用每次都跑厨房。
- 提升响应时间 —— 从内存而不是磁盘或网络提供数据。内存访问速度是纳秒级的，而磁盘 I/O 是毫秒级的，网络请求更是可能达到几十甚至上百毫秒。这就像从书桌上拿书和从图书馆借书的区别，前者秒拿，后者得等快递。
- 应对流量高峰 —— 在流量暴涨时保持系统响应。双十一、秒杀活动这些场景下，如果没有缓存，数据库分分钟被压垮。缓存就像高速公路的应急车道，关键时刻能分流大量请求。
Caffeine：你的第一道防线
Caffeine 是一个高性能的 Java 内存缓存库，基于 Google Guava 的设计理念，但性能更优。它快速、轻量，直接驻留在你的应用程序堆内存中，就像你办公桌上的常用文件盒，随手就能拿到，不需要跑到档案室。
Caffeine 的核心优势在于它的驱逐策略。它使用 Window TinyLFU 算法，这是一种自适应的缓存淘汰算法，能够根据访问模式动态调整，比传统的 LRU（最近最少使用）算法更智能。简单来说，LRU 只看最近访问时间，而 Caffeine 会综合考虑访问频率和访问时间，就像智能推荐系统，知道哪些内容更值得保留。
基础实现
import com.github.benmanes.caffeine.cache.Cache;
import com.github.benmanes.caffeine.cache.Caffeine;
import java.time.Duration;
/**
* 用户缓存类
* User cache class
* 使用 Caffeine 实现本地内存缓存
* Using Caffeine to implement local memory cache
*/
public class UserCache {
// 缓存实例，键为用户ID，值为用户对象
// Cache instance, key is user ID, value is user object
private final Cache<Long, User> cache;
public UserCache() {
cache = Caffeine.newBuilder()
// 设置最大缓存条目数，超过后会根据策略淘汰
// Set maximum cache entries, exceeding entries will be evicted based on strategy
.maximumSize(10_000)
// 写入后10分钟过期，无论是否被访问
// Expire 10 minutes after write, regardless of access
.expireAfterWrite(Duration.ofMinutes(10))
// 启用统计功能，可以监控命中率、加载时间等指标
// Enable statistics to monitor hit rate, load time and other metrics
.recordStats()
.build();
}
/**
* 获取用户信息
* Get user information
* 如果缓存中存在，直接返回；否则从数据库加载并缓存
* If exists in cache, return directly; otherwise load from database and cache
*/
public User getUser(Long userId) {
// get 方法的第二个参数是加载函数，缓存未命中时自动调用
// The second parameter of get method is a loading function, called automatically on cache miss
return cache.get(userId, id -> userRepository.findById(id));
}
}
这个缓存最多容纳 10,000 个用户，条目在写入 10 分钟后过期，并且跟踪统计信息用于监控。maximumSize 的作用是防止内存无限增长，就像给文件盒设置容量上限，满了就得扔掉一些不常用的。expireAfterWrite 确保数据不会永远停留在缓存中，避免读到过期信息。
使用刷新机制避免惊群效应
import com.github.benmanes.caffeine.cache.LoadingCache;
/**
* 商品缓存，使用刷新机制避免缓存穿透
* Product cache using refresh mechanism to avoid cache penetration
*/
LoadingCache<String, ProductList> productCache = Caffeine.newBuilder()
.maximumSize(1_000)
// 写入后30分钟过期
// Expire 30 minutes after write
.expireAfterWrite(Duration.ofMinutes(30))
// 写入后25分钟开始异步刷新，在过期前更新数据
// Start async refresh 25 minutes after write, update data before expiration
.refreshAfterWrite(Duration.ofMinutes(25))
// 构建 LoadingCache，自动处理加载逻辑
// Build LoadingCache, automatically handle loading logic
.build(key -> productService.fetchProducts(key));
// 使用方式：首次调用会加载数据，后续调用直接返回缓存
// Usage: First call loads data, subsequent calls return cached data
ProductList products = productCache.get("electronics");
刷新机制会在条目过期之前异步重新加载值，从而防止惊群效应（thundering herd problem）。什么是惊群效应？就像超市打折时，所有人同时冲向货架，结果货架被挤爆。在缓存场景中，如果缓存同时过期，大量请求会同时去数据库查询，数据库压力瞬间暴增。refreshAfterWrite 让缓存提前刷新，就像超市提前补货，避免大家同时抢购。
这里有个细节需要注意：刷新是异步的，在刷新完成前，旧数据仍然可用。这保证了服务的连续性，不会因为缓存刷新导致请求失败。
Redis：跨越单机的分布式缓存
Redis 将缓存提升到了跨机器的层面。当你需要跨多个实例保持缓存一致性，或者想要在服务之间共享会话数据时，Redis 就是你的首选。如果说 Caffeine 是个人办公桌，那 Redis 就是公司的共享文件服务器，所有员工都能访问，数据统一管理。
Redis 的核心优势在于它的数据结构丰富。除了简单的 key-value，还支持字符串、列表、集合、有序集合、哈希表等多种数据结构，这让它在缓存之外还能承担更多角色，比如实现分布式锁、消息队列、排行榜等。
Spring Boot 集成配置
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.redis.cache.RedisCacheConfiguration;
import org.springframework.data.redis.cache.RedisCacheManager;
import org.springframework.data.redis.connection.RedisConnectionFactory;
import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;
import org.springframework.data.redis.serializer.RedisSerializationContext;
import org.springframework.data.redis.serializer.StringRedisSerializer;
import java.time.Duration;
/**
* Redis 缓存配置类
* Redis cache configuration class
*/
@Configuration
@EnableCaching // 启用 Spring 缓存抽象
public class RedisConfig {
/**
* 配置 Redis 缓存管理器
* Configure Redis cache manager
*/
@Bean
public RedisCacheManager cacheManager(RedisConnectionFactory connectionFactory) {
RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
// 设置缓存过期时间为 60 分钟
// Set cache expiration time to 60 minutes
.entryTtl(Duration.ofMinutes(60))
// 键使用字符串序列化，便于在 Redis 中查看
// Key uses string serialization for easy viewing in Redis
.serializeKeysWith(
RedisSerializationContext.SerializationPair
.fromSerializer(new StringRedisSerializer())
)
// 值使用 JSON 序列化，支持复杂对象
// Value uses JSON serialization, supports complex objects
.serializeValuesWith(
RedisSerializationContext.SerializationPair
.fromSerializer(new GenericJackson2JsonRedisSerializer())
)
// 禁止缓存 null 值，避免缓存穿透
// Disable caching null values to avoid cache penetration
.disableCachingNullValues();
return RedisCacheManager.builder(connectionFactory)
.cacheDefaults(config)
.build();
}
}
这个配置有几个关键点：序列化方式的选择很重要。键用字符串序列化，这样在 Redis 客户端可以直接看到可读的键名；值用 JSON 序列化，既能存储复杂对象，又便于跨语言使用。disableCachingNullValues() 防止缓存空值，避免缓存穿透问题。
使用注解的声明式缓存
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
/**
* 订单服务，演示声明式缓存的使用
* Order service demonstrating declarative cache usage
*/
@Service
public class OrderService {
/**
* 获取订单，如果缓存中存在则直接返回
* Get order, return directly if exists in cache
* @Cacheable 表示方法结果会被缓存，value 指定缓存名称，key 指定缓存键
* @Cacheable indicates method result will be cached, value specifies cache name, key specifies cache key
*/
@Cacheable(value = "orders", key = "#orderId")
public Order getOrder(Long orderId) {
// 只有缓存未命中时才会执行这里的代码
// This code only executes on cache miss
return orderRepository.findById(orderId);
}
/**
* 更新订单，同时清除缓存
* Update order and clear cache simultaneously
* @CacheEvict 表示方法执行后会清除指定缓存
* @CacheEvict indicates cache will be cleared after method execution
*/
@CacheEvict(value = "orders", key = "#order.id")
public Order updateOrder(Order order) {
return orderRepository.save(order);
}
}
注解使缓存变得声明式，代码简洁优雅，但要小心——它们隐藏了可能咬你一口的复杂性。比如异常处理、缓存失效的时机、分布式环境下的缓存一致性等问题，都需要仔细考虑。在实际项目中，建议先用注解快速实现，遇到复杂场景再考虑手动控制缓存。
如何选择
选择缓存方案就像选工具，得看场景。下面这张表帮你快速决策：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 高性能、低延迟的内存缓存 | Caffeine | 本地内存访问，延迟最低，适合对响应时间要求极高的场景 |
| 中小型数据集，可完全放入内存 | Caffeine | 数据量不大，单机内存足够，没必要引入分布式组件 |
| 受益于动态自适应驱逐策略 | Caffeine | 访问模式复杂，需要智能的缓存淘汰算法 |
| 不需要持久化或分布式缓存 | Caffeine | 单机应用，数据丢失可接受，重启后重新加载 |
| 跨多节点/实例的分布式缓存 | Redis | 微服务架构，多个实例需要共享缓存数据 |
| 多个应用实例间共享数据 | Redis | 比如用户会话、购物车等需要跨服务共享的数据 |
| 需要会话共享或分布式锁 | Redis | Redis 的数据结构和原子操作非常适合这些场景 |
| 需要缓存持久化 | Redis | 数据重要，不能因为服务重启而丢失 |
实际项目中，很多场景并不是非此即彼。比如电商系统，商品详情这种热点数据用 Caffeine 做本地缓存，用户购物车这种需要跨服务共享的用 Redis。关键是要理解业务需求，选择最合适的方案。
两级缓存=两全其美
在实际生产环境中，最佳实践通常是结合两者的优势，构建多级缓存架构。这就像城市的交通系统，有快速路（L1）、主干道（L2）和普通道路（L3），不同级别的道路承担不同流量。
L1 缓存（Caffeine）：最快，内存级别，JVM 本地。这是第一道防线，命中率通常能达到 80% 以上，响应时间在微秒级。适合缓存热点数据，比如首页商品列表、用户基本信息等。
L2 缓存（Redis）：共享的分布式缓存，所有实例可访问。当 L1 未命中时，从这里获取数据，响应时间在毫秒级。适合缓存访问频率中等的数据，比如商品详情、订单信息等。
L3（可选）：持久化存储（如数据库或 API）。这是最后一道防线，数据最全但最慢。只有前两级都未命中时才会访问这里。
多级缓存流程
客户端请求 → Caffeine（命中？返回）
↓ 未命中
Redis（命中？返回 & 回填 Caffeine）
↓ 未命中
数据库（返回 & 回填两级缓存）
这个流程有几个关键点：回填机制很重要，从 Redis 或数据库获取数据后，要回填到上一级缓存，这样下次请求就能更快命中。缓存预热也很重要，系统启动时可以预先加载热点数据到 L1 和 L2，避免冷启动时的性能问题。
避坑指南
在实际项目中，缓存用好了是神器，用不好就是坑。下面这些经验教训，都是血泪换来的：
配置合理的缓存大小 —— 使用 maximumSize 方法根据应用需求限制缓存大小。不要设置得太大，否则会占用过多堆内存，导致频繁 GC；也不要设置得太小，否则命中率低，缓存失去意义。一般建议设置为预估数据量的 1.5-2 倍，给缓存一些冗余空间。
不要忽略过期策略 —— 使用 expireAfterWrite 或 expireAfterAccess 防止陈旧数据。过期时间要根据业务特点设置，比如用户信息可以设置得长一些（30 分钟），商品价格这种变化频繁的要短一些（5 分钟）。记住，过期时间不是越长越好，要在数据新鲜度和缓存命中率之间找平衡。
处理缓存未命中 —— 始终检查 null 或使用带加载函数的 get 方法提供默认值。缓存未命中是正常现象，关键是要优雅处理。使用 LoadingCache 或带加载函数的 get 方法，可以自动处理未命中情况，避免代码中到处都是 null 检查。
注意缓存一致性 —— 在分布式环境中，本地缓存可能导致数据不一致。比如用户在一个实例更新了信息，其他实例的本地缓存还是旧数据。解决方案有几种：使用 Redis 发布订阅机制通知其他实例失效缓存，或者设置较短的过期时间，或者干脆不用本地缓存，只用 Redis。
实现优雅降级 —— 当 Redis 宕机时，使用断路器回退到本地缓存。分布式系统总有故障的时候，要有容错机制。可以使用 Hystrix 或 Resilience4j 实现断路器模式，当 Redis 不可用时，自动切换到本地缓存或直接查数据库，保证服务可用性。
监控缓存指标 —— 使用 recordStats() 启用统计功能，定期查看命中率、加载时间等指标。命中率太低说明缓存配置不合理，加载时间太长说明数据源性能有问题。这些指标是优化缓存的重要依据。
总结
缓存虽常被认为是提升性能的捷径，但实际应用中充满挑战。Caffeine 擅长单节点高性能场景，Redis 适合分布式共享，两者结合更能兼顾速度与扩展性。在选择缓存方案时，要结合具体业务与架构场景，并深入理解其原理，合理配置，才能真正发挥缓存对 Java 应用性能和可扩展性的提升作用。