文章目录
- 前言
- 一、Spring Cache核心原理
- 1.1 架构设计思想
- 1.2 运行时执行流程
- 1.3 核心组件协作
- 1.4 关键机制详解
- 1.5 扩展点设计
- 1.6 与Spring事务的协同
- 二、快速入门实战
- 三、局限性
- 3.1 多级缓存一致性缺陷
- 3.2 分布式锁能力缺失
- 3.3 事务集成陷阱
- 总结
前言
在当今高并发、低延迟的应用生态中，缓存是提升系统性能的核心武器。但传统缓存实现往往让开发者陷入两难困境：
- 当你在方法中重复编写这样的代码时，是否感到窒息？
// 典型的手动缓存管理（每个方法都需要）
public Product getProduct(String id) {
Product cached = cache.get("product_" + id);
if (cached != null) return cached;
Product dbData = productDao.findById(id); // 真实业务逻辑被淹没
if (dbData != null) cache.set("product_" + id, dbData, 300);
return dbData;
}
- 当系统需要支持多级缓存（本地缓存+Redis）时，代码复杂度是否呈指数级增长？
- 当缓存穿透、雪崩等问题袭来时，你的业务逻辑是否已变成防御性代码的牺牲品？
Spring Cache的设计思想：
- 关注点分离： 缓存逻辑与业务代码彻底解耦。
@Cacheable("products") // 业务逻辑纯净如初
public Product getProduct(String id) {
return productDao.findById(id);
}
- 统一抽象层： 无缝切换缓存实现，无代码侵入。
- 智能缓存治理： 自动处理缓存一致性，规避脏数据风险。
@Caching(
evict = @CacheEvict(key = "#product.id"),
put = @CachePut(key = "#product.sku")
) // 原子化缓存操作
public void updateProduct(Product product) { ... }
- 生产级防御体系：
# 内置防护机制
spring.cache:
caffeine.spec: maximumSize=1000, expireAfterWrite=5m
redis.cache-null-values: false # 防穿透
cache-prefix: "app_cache_" # 防冲突
本文将深入剖析Spring Cache的运行时架构，并提供快速入门实战。
一、Spring Cache核心原理
Spring Cache的核心原理是通过动态代理机制在方法调用前后植入缓存逻辑，基于抽象接口层（CacheManager统一管理Cache实例）实现对多种缓存实现的统一操作，其执行流程为：当调用@Cacheable方法时，缓存拦截器首先通过KeyGenerator生成缓存键，查询Cache实例是否存在缓存；若命中则直接返回，否则执行原始方法并将结果写入Cache，而@CachePut会强制更新缓存，@CacheEvict则负责清除缓存条目。整个过程通过CacheOperationSource解析注解配置，CacheResolver动态选择缓存实例，最终由CacheInterceptor协调完成缓存操作，实现了业务逻辑与缓存管理的彻底解耦。
1.1 架构设计思想
抽象分层设计：
- 应用层：@Cacheable等注解
- 抽象层：Cache/CacheManager接口
- 实现层：Caffeine/Redis/Ehcache等适配器
接口核心定义：
public interface Cache {
String getName(); // 缓存名称
Object get(Object key); // 读操作
void put(Object key, Object value); // 写操作
void evict(Object key); // 删除
}
public interface CacheManager {
Cache getCache(String name); // 获取缓存实例
Collection<String> getCacheNames(); // 所有缓存名
}
1.2 运行时执行流程
以 @Cacheable 为例的完整调用链：
关键步骤详解：
- 代理拦截： 当客户端调用带有@Cacheable注解的方法时，Spring AOP创建的动态代理对象首先拦截该调用。代理对象将控制权交给CacheInterceptor。
- 注解解析：
CacheInterceptor委托CacheAspectSupport解析缓存操作：- 解析注解参数（value、key、condition等）
- 生成CacheOperationContext执行上下文
- 通过KeyGenerator计算缓存键（默认使用所有方法参数）
- 缓存查询：
通过CacheManager获取对应的Cache实例，使用生成的key执行cache.get()操作：- 命中：直接返回缓存结果（跳过业务方法执行）
- 未命中：继续执行原始方法
- 业务方法执行：
仅当缓存未命中时：- 通过MethodInvocation.proceed()执行实际业务逻辑
- 业务方法可能访问数据库或进行复杂计算
- 结果缓存：
业务方法执行完成后：- 检查unless条件（结果不为空等）
- 通过cache.put()将结果写入缓存
- 设置TTL（如果缓存实现支持）
- 结果返回
1.3 核心组件协作
- 缓存操作解析器 - CacheOperationSource
作为Spring Cache的注解解析引擎，CacheOperationSource通过反射分析方法的@Cacheable、@CacheEvict等注解，将其转换为可执行的CacheOperation对象（包含缓存名称、Key表达式、条件等元数据）。其核心作用是在运行时动态构建缓存操作上下文，使CacheInterceptor能基于统一的操作模型处理不同注解，实现"注解配置→缓存行为"的桥接，具体流程为：- 元数据提取： 解析方法/类上的缓存注解，生成CacheOperation集合。
- EL表达式处理： 解析SpEL表达式（如#id、#result），绑定到运行时上下文。
- 条件预判： 提前验证condition表达式，决定是否启用缓存逻辑。
- 多注解合并： 处理@Caching组合注解，合并多个缓存操作。
public interface CacheOperationSource {
// 解析方法上的缓存注解
Collection<CacheOperation> getCacheOperations(Method method, Class<?> targetClass);
}
- 缓存键生成器 - KeyGenerator
作为Spring Cache的缓存键生成器，KeyGenerator通过算法将方法调用信息（参数、目标对象等）转换为唯一的缓存键（Cache Key），其核心作用是确保相同业务逻辑输入对应固定缓存键，避免数据错乱。默认实现SimpleKeyGenerator按以下规则工作：- 无参数方法： 返回SimpleKey.EMPTY空键。
- 单参数方法： 直接使用参数对象作为键（需实现hashCode/equals）。
- 多参数方法： 组合所有参数生成SimpleKey。
// 默认实现逻辑（简化版）
public Object generate(Object target, Method method, Object... params) {
if (params.length == 0) {
return SimpleKey.EMPTY;
}
if (params.length == 1) {
return params[0]; // 直接使用参数
}
return new SimpleKey(params); // 多参数组合
}
- 缓存解析器 - CacheResolver
CacheResolver是Spring Cache的动态缓存实例决策器，其核心作用是在运行时根据方法调用上下文（如参数、注解配置等）动态确定使用哪个或哪些Cache实例，实现多缓存灵活路由。其原理是通过解析@Cacheable等注解的value/cacheNames属性，结合当前缓存配置，返回最终参与操作的Cache对象集合，支持以下能力：- 基础路由： 将注解中的缓存名称（如@Cacheable(“users”)）转换为具体的Cache实例。
- 动态选择： 基于方法参数或运行环境动态切换缓存（如多租户场景按tenantId选择不同Cache）
- 多缓存操作： 支持一个方法同时读写多个缓存（如主备缓存策略）。
// 典型实现：SimpleCacheResolver
public Collection<? extends Cache> resolveCaches(CacheOperationInvocationContext<?> context) {
// 根据@Cacheable的value值从CacheManager获取对应Cache实例
return context.getOperation().getCacheNames().stream()
.map(name -> cacheManager.getCache(name))
.filter(Objects::nonNull)
.collect(Collectors.toList());
}
- 缓存拦截器 - CacheInterceptor
CacheInterceptor是Spring Cache的执行中枢，作为AOP拦截器（MethodInterceptor实现），它在目标方法调用前后植入缓存逻辑，协调CacheOperationSource、KeyGenerator、CacheResolver等组件完成完整的缓存操作流程。其核心原理是通过责任链模式，将@Cacheable/@CachePut/@CacheEvict等注解的语义转化为具体的缓存读写行为，实现以下核心功能：- 缓存决策： 根据CacheOperationSource解析的注解配置，判断是否启用缓存逻辑。
- 键值管理： 调用KeyGenerator生成缓存键，通过CacheResolver定位目标Cache实例。
- 缓存读写： 执行"查缓存→执行业务→写缓存"的标准流程（@Cacheable）或强制更新（@CachePut）。
- 异常处理： 通过CacheErrorHandler处理缓存访问异常，支持降级策略。
public class CacheInterceptor extends CacheAspectSupport implements MethodInterceptor {
public Object invoke(MethodInvocation invocation) {
// 核心拦截逻辑
return execute(invocation, invocation.getThis(),
invocation.getMethod(), invocation.getArguments());
}
}
关键逻辑：
protected Object execute(CacheOperationInvoker invoker, Object target,
Method method, Object[] args) {
// 1. 获取缓存操作
CacheOperationContext context = getOperationContext(operation, method, args);
// 2. 处理@Cacheable
if (isCacheableOperation(context)) {
return processCacheable(context, invoker);
}
// 3. 处理@CachePut
else if (isPutOperation(context)) {
return processPut(context, invoker);
}
// 4. 处理@CacheEvict
else if (isEvictOperation(context)) {
processEvict(context);
return invoker.invoke();
}
}
1.4 关键机制详解
- 代理创建机制
- JDK动态代理：代理接口实现类
- CGLIB代理：代理无接口的类
- 代理触发条件：存在@Cacheable/@CachePut/@CacheEvict注解
- 缓存同步控制
@Cacheable(value="users", sync=true) // 启用同步锁
public User getUser(String id) {...}
- 多线程并发时，只有一个线程执行真实方法
- 基于ConcurrentMap的putIfAbsent实现
- 条件缓存实现原理
@Cacheable(condition = "#id.length() > 5")
执行流程：
- 解析SpEL表达式
- 创建ConditionEvaluator
- 在CacheAspectSupport中判断：
if (!context.canCacheBeApplied()) {
return invoker.invoke(); // 跳过缓存
}
- 缓存异常处理
@Cacheable(unless = "#result == null") // 结果为空不缓存
@Cacheable(unless = "#exception != null") // 异常时不缓存
- unless在方法执行后评估
- condition在方法执行前评估
1.5 扩展点设计
Spring Cache提供丰富的扩展接口：
| 扩展点 | 作用 | 典型场景 |
|---|---|---|
| KeyGenerator | 自定义缓存键生成策略 | 复合键、业务键转换 |
| CacheResolver | 动态解析缓存实例 | 多租户缓存隔离 |
| CacheErrorHandler | 处理缓存读写异常 | 缓存降级策略 |
| CacheManagerCustomizer | 缓存管理器定制 | 初始化缓存配置 |
| CacheLoader | 缓存加载器 (JCache) | 自动刷新缓存 |
自定义KeyGenerator示例：
@Bean
public KeyGenerator businessKeyGenerator() {
return (target, method, params) ->
method.getName() + "_" +
((User)params[0]).getCompanyId() + "_" +
((User)params[0]).getDepartmentId();
}
1.6 与Spring事务的协同
关键点：
- 缓存操作在事务提交后执行
- 避免事务回滚导致缓存不一致
二、快速入门实战
- 添加依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
</dependency>
- 启用缓存
@SpringBootApplication
@EnableCaching // 启用缓存
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
- 配置缓存（application.yml）
spring:
cache:
type: caffeine
caffeine:
spec: maximumSize=500, expireAfterWrite=10m
- 实现缓存服务
@Service
public class BookService {
// 查询时缓存结果
@Cacheable(value = "books", key = "#isbn")
public Book getBook(String isbn) {
// 模拟数据库查询
return fetchFromDatabase(isbn);
}
// 更新时刷新缓存
@CachePut(value = "books", key = "#book.isbn")
public Book updateBook(Book book) {
return saveToDatabase(book);
}
// 删除时清除缓存
@CacheEvict(value = "books", key = "#isbn")
public void deleteBook(String isbn) {
deleteFromDatabase(isbn);
}
}
- 测试验证
@RestController
@RequestMapping("/books")
public class BookController {
@Autowired
private BookService bookService;
@GetMapping("/{isbn}")
public Book getBook(@PathVariable String isbn) {
// 首次调用访问数据库，后续请求直接读缓存
return bookService.getBook(isbn);
}
}
三、局限性
Spring Cache 虽然在简化缓存集成方面表现出色，但在复杂场景下存在明显的局限性：
3.1 多级缓存一致性缺陷
Spring Cache 的抽象层未原生支持本地缓存（如 Caffeine）与分布式缓存（如 Redis）的自动同步，导致：
- 节点间数据不一致：服务A更新数据后，服务B的本地缓存仍为旧值。
- 级联更新缺失：无法自动感知数据库变更（如通过Binlog）。
// 服务A更新数据
@CachePut("users")
public User updateUser(User user) {
db.update(user);
return user; // 仅更新当前节点的本地缓存和Redis
}
// 服务B仍读取到本地旧值
解决方案：
- 集成 JetCache 或 Ehcache+Terracotta 等支持多级同步的框架。
- 自定义 CacheManager 实现基于消息队列（如Kafka）的失效广播。
3.2 分布式锁能力缺失
@Cacheable(sync=true) 仅支持单机同步，无法解决分布式环境下的并发控制：
- 热点数据并发查询：多个节点同时缓存未命中，导致数据库被击穿。
- 复合操作竞争：如库存扣减需跨服务原子性。
@Cacheable(value = "inventory", sync = true) // 仅单机有效
public Integer getInventory(String sku) {
return db.query("SELECT stock FROM inventory WHERE sku=?", sku);
}
解决方案：
- 集成 Redisson实现分布式锁。
- 改用 Redis Lua脚本 保证原子性。
3.3 事务集成陷阱
虽然支持事务绑定，但存在隐蔽问题：
- 脏读风险：@Cacheable 在事务提交前可能读取到未提交数据。
- 跨事务污染：事务回滚时缓存已更新。
@Transactional
@CacheEvict("orders")
public void updateOrder(Order order) {
db.update(order); // 若事务回滚，缓存已被清除
}
解决方案：
- 使用 TransactionSynchronizationManager 注册事务回调。
- 采用 最终一致性 模式（如通过CDC同步）。
总结
Spring Cache 通过动态代理和统一抽象层简化了缓存集成，适合处理标准 CRUD 场景，但其在多级缓存同步、分布式锁等方面存在明显局限，复杂场景下需结合 Redisson/JetCache 等专业框架扩展，更适合作为基础缓存抽象层而非全功能解决方案。
