玩转Spring Cache --- @Cacheable/@CachePut/@CacheEvict注解的原理深度剖析和使用【享学Spring】_spring cache cacheable sync

每篇一句

坚持系统化的学习方式，由量变到质变。仅仅解决工作中的问题，并不能叫系统化的学习

前言

上篇文章介绍了@EnableCaching，用它来开启Spring对缓存注解的支持。本篇文章将继续分析Spring Cache，并且讲解的是我们最为关心的：缓存注解实操方面的原理支持和使用。

开发过程中因注解的优雅、使用简单使得这种方式广泛被大家所接受和使用，本文将按照先原理，再实操的步骤，一步步解惑Spring缓存注解的原理

缓存注解

关于Spring的缓存注解，一共有如下5个：

1. @Cacheable：缓存

// @since 3.1  可以标注在方法上、类上  下同
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Cacheable {
	// 缓存名称  可以写多个~
	@AliasFor("cacheNames")
	String[] value() default {};
	@AliasFor("value")
	String[] cacheNames() default {};

	// 支持写SpEL，切可以使用#root
	String key() default "";
	// Mutually exclusive：它和key属性互相排斥。请只使用一个
	String keyGenerator() default "";

	String cacheManager() default "";
	String cacheResolver() default "";

	// SpEL，可以使用#root。  只有true时，才会作用在这个方法上
	String condition() default "";
	// 可以写SpEL #root，并且可以使用#result拿到方法返回值~~~
	String unless() default "";
	
	// true：表示强制同步执行。（若多个线程试图为**同一个键**加载值，以同步的方式来进行目标方法的调用）
	// 同步的好处是：后一个线程会读取到前一个缓存的缓存数据，不用再查库了~~~ 
	// 默认是false，不开启同步one by one的
	// @since 4.3  注意是sync而不是Async
	// 它的解析依赖于Spring4.3提供的Cache.get(Object key, Callable<T> valueLoader);方法
	boolean sync() default false;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

2. @CachePut：缓存更新

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Cacheable {

	@AliasFor("cacheNames")
	String[] value() default {};
	@AliasFor("value")
	String[] cacheNames() default {};

	// 注意：它和上面区别是。此处key它还能使用#result
	String key() default "";
	String keyGenerator() default "";

	String cacheManager() default "";
	String cacheResolver() default "";

	String condition() default "";
	String unless() default "";
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

3. @CacheEvict：缓存删除

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Cacheable {

	@AliasFor("cacheNames")
	String[] value() default {};
	@AliasFor("value")
	String[] cacheNames() default {};

	// 它也能使用#result
	String key() default "";
	String keyGenerator() default "";

	String cacheManager() default "";
	String cacheResolver() default "";
	String condition() default "";

	// 是否把上面cacheNames指定的所有的缓存都清除掉，默认false
	boolean allEntries() default false;
	// 是否让清理缓存动作在目标方法之前执行，默认是false（在目标方法之后执行）
	// 注意：若在之后执行的话，目标方法一旦抛出异常了，那缓存就清理不掉了~~~~
	boolean beforeInvocation() default false;

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

4. @Caching：用于处理复杂的缓存情况。比如用户既要根据id缓存一份，也要根据电话缓存一份，还要根据电子邮箱缓存一份，就可以使用它

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface Caching {
	Cacheable[] cacheable() default {};
	CachePut[] put() default {};
	CacheEvict[] evict() default {};
}
1
2
3
4
5
6
7
8
9

5. @CacheConfig：可以在类级别上标注一些共用的缓存属性。（所有方法共享，@since 4.1）

// @since 4.1 出现得还是比较晚的
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CacheConfig {
	String[] cacheNames() default {};
	String keyGenerator() default "";
	String cacheManager() default "";
	String cacheResolver() default "";
}
1
2
3
4
5
6
7
8
9
10

属性说明表格：

原理分析

先阅读：【小家Spring】玩转Spring Cache — @Cacheable/@CachePut/@CacheEvict缓存注解相关基础类打点 再读本文，效果会像德芙一般丝滑~

从上篇文章中已经知道了@EnableCaching主要向容器注入了三个Bean：CacheOperationSource、BeanFactoryCacheOperationSourceAdvisor、CacheInterceptor。他们是让注解生效的核心类。

CacheOperationSource

它代表缓存操作源，已经分析过。

BeanFactoryCacheOperationSourceAdvisor

从名字就能看出它是一个增强器Advisor，并且还和BeanFactory有关。

	@Bean(name = CacheManagementConfigUtils.CACHE_ADVISOR_BEAN_NAME)
	@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
	public BeanFactoryCacheOperationSourceAdvisor cacheAdvisor() {
		BeanFactoryCacheOperationSourceAdvisor advisor = new BeanFactoryCacheOperationSourceAdvisor();
		advisor.setCacheOperationSource(cacheOperationSource());
		advisor.setAdvice(cacheInterceptor());
		if (this.enableCaching != null) {
			advisor.setOrder(this.enableCaching.<Integer>getNumber("order"));
		}
		return advisor;
	}
1
2
3
4
5
6
7
8
9
10
11

从上配置知道，这个增强器的切面Advice是CacheInterceptor，并且持有CacheOperationSource的引用。

public class BeanFactoryCacheOperationSourceAdvisor extends AbstractBeanFactoryPointcutAdvisor {
	@Nullable
	private CacheOperationSource cacheOperationSource;

	// 切面Pointcut
	private final CacheOperationSourcePointcut pointcut = new CacheOperationSourcePointcut() {
		@Override
		@Nullable
		protected CacheOperationSource getCacheOperationSource() {
			return cacheOperationSource;
		}
	};

	public void setCacheOperationSource(CacheOperationSource cacheOperationSource) {
		this.cacheOperationSource = cacheOperationSource;
	}

	// 注意：此处你可以自定义一个ClassFilter，过滤掉你想忽略的类
	public void setClassFilter(ClassFilter classFilter) {
		this.pointcut.setClassFilter(classFilter);
	}

	@Override
	public Pointcut getPointcut() {
		return this.pointcut;
	}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

此Advisor的实现非常的简单，切点是CacheOperationSourcePointcut，核心逻辑都依托于缓存属性源。所以还没有看这块的，此处再一次推荐：【小家Spring】玩转Spring Cache — @Cacheable/@CachePut/@CacheEvict缓存注解相关基础类打点

CacheInterceptor

缓存拦截器。先说明一点，它的实现模式几乎和TransactionInterceptor一毛一样。所以我又想建议一句了，有空先看看它吧：【小家Spring】源码分析Spring的事务拦截器：TransactionInterceptor和事务管理器：PlatformTransactionManager

同样，CacheInterceptor是缓存真正执行的核心，处理逻辑还是稍显复杂的。

// @since 3.1  它是个MethodInterceptor环绕增强器~~~
public class CacheInterceptor extends CacheAspectSupport implements MethodInterceptor, Serializable {

	@Override
	@Nullable
	public Object invoke(final MethodInvocation invocation) throws Throwable {
		Method method = invocation.getMethod();

		// 采用函数的形式，最终把此函数传交给父类的execute()去执行
		// 但是很显然，最终**执行目标方法**的是invocation.proceed();它
		
		//这里就是对执行方法调用的一次封装，主要是为了处理对异常的包装。
		CacheOperationInvoker aopAllianceInvoker = () -> {
			try {
				return invocation.proceed();
			}
			catch (Throwable ex) {
				throw new CacheOperationInvoker.ThrowableWrapper(ex);
			}
		};

		try {
			// //真正地去处理缓存操作的执行，很显然这是父类的方法，所以我们要到父类CacheAspectSupport中去看看。
			return execute(aopAllianceInvoker, invocation.getThis(), method, invocation.getArguments());
		} catch (CacheOperationInvoker.ThrowableWrapper th) {
			throw th.getOriginal();
		}
	}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

这个类本身的实现很少，主要逻辑都在他的抽象父类：CacheAspectSupport

CacheAspectSupport

它类似于TransactionAspectSupport，父类实现了所有的核心逻辑

// @since 3.1  它相较于TransactionAspectSupport额外实现了SmartInitializingSingleton接口
// SmartInitializingSingleton应该也不会陌生。它在初始化完所有的单例Bean后会执行这个接口的`afterSingletonsInstantiated()`方法
// 比如我们熟悉的ScheduledAnnotationBeanPostProcessor、EventListenerMethodProcessor都是这么来处理的

// 另外还需要注意，它还继承自AbstractCacheInvoker：主要对异常情况用CacheErrorHandler处理
public abstract class CacheAspectSupport extends AbstractCacheInvoker implements BeanFactoryAware, InitializingBean, SmartInitializingSingleton {

	// CacheOperationCacheKey：缓存的key  CacheOperationMetadata就是持有一些基础属性的性息
	// 这个缓存挺大，相当于每一个类、方法都有气对应的**缓存属性元数据**
	
	private final Map<CacheOperationCacheKey, CacheOperationMetadata> metadataCache = new ConcurrentHashMap<>(1024);
	// 解析一些condition、key、unless等可以写el表达式的处理器~~~
	// 之前讲过的熟悉的有：EventExpressionEvaluator
	private final CacheOperationExpressionEvaluator evaluator = new CacheOperationExpressionEvaluator();
	// 属性源，默认情况下是基于注解的`AnnotationCacheOperationSource`
	@Nullable
	private CacheOperationSource cacheOperationSource;
	// 看到了吧  key生成器默认使用的SimpleKeyGenerator
	// 注意SingletonSupplier是Spring5.1的新类，实现了接口java.util.function.Supplier  主要是对null值进行了容错
	private SingletonSupplier<KeyGenerator> keyGenerator = SingletonSupplier.of(SimpleKeyGenerator::new);

	@Nullable
	private SingletonSupplier<CacheResolver> cacheResolver;
	@Nullable
	private BeanFactory beanFactory;
	private boolean initialized = false;

	// @since 5.1
	public void configure(@Nullable Supplier<CacheErrorHandler> errorHandler, @Nullable Supplier<KeyGenerator> keyGenerator,@Nullable Supplier<CacheResolver> cacheResolver, @Nullable Supplier<CacheManager> cacheManager) {
		// 第二个参数都是默认值，若调用者没传的话
		this.errorHandler = new SingletonSupplier<>(errorHandler, SimpleCacheErrorHandler::new);
		this.keyGenerator = new SingletonSupplier<>(keyGenerator, SimpleKeyGenerator::new);
		this.cacheResolver = new SingletonSupplier<>(cacheResolver, () -> SimpleCacheResolver.of(SupplierUtils.resolve(cacheManager)));
	}

	// 此处：若传入了多个cacheOperationSources，那最终使用的就是CompositeCacheOperationSource包装起来
	// 所以发现，Spring是支持我们多种 缓存属性源的
	public void setCacheOperationSources(CacheOperationSource... cacheOperationSources) {
		Assert.notEmpty(cacheOperationSources, "At least 1 CacheOperationSource needs to be specified");
		this.cacheOperationSource = (cacheOperationSources.length > 1 ? new CompositeCacheOperationSource(cacheOperationSources) : cacheOperationSources[0]);
	}
	// @since 5.1 单数形式的设置
	public void setCacheOperationSource(@Nullable CacheOperationSource cacheOperationSource) {
		this.cacheOperationSource = cacheOperationSource;
	}
	
	... // 省略各种get/set方法~~~

	// CacheOperationSource必须不为null，因为一切依托于它
	@Override
	public void afterPropertiesSet() {
		Assert.state(getCacheOperationSource() != null, "The 'cacheOperationSources' property is required: " + "If there are no cacheable methods, then don't use a cache aspect.");
	}

	// 这个来自于接口：SmartInitializingSingleton  在实例化完所有单例Bean后调用
	@Override
	public void afterSingletonsInstantiated() {
		// 若没有给这个切面手动设置cacheResolver  那就去拿CacheManager吧
		// 这就是为何我们只需要把CacheManager配进容器里即可  就自动会设置在切面里了
		if (getCacheResolver() == null) {
			// Lazily initialize cache resolver via default cache manager...
			Assert.state(this.beanFactory != null, "CacheResolver or BeanFactory must be set on cache aspect");
			try {
				// 请注意：这个方法实际上是把CacheManager包装成了一个SimpleCacheResolver
				// 所以最终还是给SimpleCacheResolver赋值
				setCacheManager(this.beanFactory.getBean(CacheManager.class));
			} ...
		}
		this.initialized = true;
	}

	// 主要为了输出日志，子类可复写
	protected String methodIdentification(Method method, Class<?> targetClass) {
		Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass);
		return ClassUtils.getQualifiedMethodName(specificMethod);
	}

	// 从这里也能看出，至少要指定一个Cache才行（也就是cacheNames）
	protected Collection<? extends Cache> getCaches(CacheOperationInvocationContext<CacheOperation> context, CacheResolver cacheResolver) {

		Collection<? extends Cache> caches = cacheResolver.resolveCaches(context);
		if (caches.isEmpty()) {
			throw new IllegalStateException("No cache could be resolved for '" +
					context.getOperation() + "' using resolver '" + cacheResolver +
					"'. At least one cache should be provided per cache operation.");
		}
		return caches;
	}


	// 这个根据CacheOperation 这部分还是比较重要的
	protected CacheOperationMetadata getCacheOperationMetadata(CacheOperation operation, Method method, Class<?> targetClass) {
		CacheOperationCacheKey cacheKey = new CacheOperationCacheKey(operation, method, targetClass);
		CacheOperationMetadata metadata = this.metadataCache.get(cacheKey);


		if (metadata == null) {
			// 1、指定了KeyGenerator就去拿这个Bean（没有就报错，所以key不要写错了）
			// 没有指定就用默认的
			KeyGenerator operationKeyGenerator;
			if (StringUtils.hasText(operation.getKeyGenerator())) {
				operationKeyGenerator = getBean(operation.getKeyGenerator(), KeyGenerator.class);
			} else {
				operationKeyGenerator = getKeyGenerator();
			}

			// 1、自己指定的CacheResolver
			// 2、再看指定的的CacheManager,包装成一个SimpleCacheResolver
			// 3、
			CacheResolver operationCacheResolver;
			if (StringUtils.hasText(operation.getCacheResolver())) {
				operationCacheResolver = getBean(operation.getCacheResolver(), CacheResolver.class);
			} else if (StringUtils.hasText(operation.getCacheManager())) {
				CacheManager cacheManager = getBean(operation.getCacheManager(), CacheManager.class);
				operationCacheResolver = new SimpleCacheResolver(cacheManager);
			} else { //最终都没配置的话，取本切面默认的
				operationCacheResolver = getCacheResolver();
				Assert.state(operationCacheResolver != null, "No CacheResolver/CacheManager set");
			}

			// 封装成Metadata
			metadata = new CacheOperationMetadata(operation, method, targetClass, operationKeyGenerator, operationCacheResolver);
			this.metadataCache.put(cacheKey, metadata);
		}
		return metadata;
	}

	// qualifiedBeanOfType的意思是，@Bean类上面标注@Qualifier注解也生效
	protected <T> T getBean(String beanName, Class<T> expectedType) {
		if (this.beanFactory == null) {
			throw new IllegalStateException(
					"BeanFactory must be set on cache aspect for " + expectedType.getSimpleName() + " retrieval");
		}
		return BeanFactoryAnnotationUtils.qualifiedBeanOfType(this.beanFactory, expectedType, beanName);
	}

	// 请Meta数据的缓存
	protected void clearMetadataCache() {
		this.metadataCache.clear();
		this.evaluator.clear();
	}


	// 父类最为核心的方法，真正执行目标方法 + 缓存操作
	@Nullable
	protected Object execute(CacheOperationInvoker invoker, Object target, Method method, Object[] args) {
		// Check whether aspect is enabled (to cope with cases where the AJ is pulled in automatically)
		// 如果已经表示初始化过了(有CacheManager，CacheResolver了)，执行这里
		if (this.initialized) {
			// getTargetClass拿到原始Class  解剖代理（N层都能解开）
			Class<?> targetClass = getTargetClass(target);
			CacheOperationSource cacheOperationSource = getCacheOperationSource();
			
			if (cacheOperationSource != null) {
				// 简单的说就是拿到该方法上所有的CacheOperation缓存操作，最终一个一个的执行~~~~
				Collection<CacheOperation> operations = cacheOperationSource.getCacheOperations(method, targetClass);
				if (!CollectionUtils.isEmpty(operations)) {

					// CacheOperationContexts是非常重要的一个私有内部类
					// 注意它是复数哦~不是CacheOperationContext单数  所以它就像持有多个注解上下文一样  一个个执行吧
					// 所以我建议先看看此类的描述，再继续往下看~~~
					return execute(invoker, method, new CacheOperationContexts(operations, method, args, target, targetClass));
				}
			}
		}

		// 若还没初始化  直接执行目标方法即可
		return invoker.invoke();
	}



	@Nullable
	private Object execute(final CacheOperationInvoker invoker, Method method, CacheOperationContexts contexts) {
		// Special handling of synchronized invocation
		// 如果是需要同步执行的话，这块还是
		if (contexts.isSynchronized()) {
			CacheOperationContext context = contexts.get(CacheableOperation.class).iterator().next();
			if (isConditionPassing(context, CacheOperationExpressionEvaluator.NO_RESULT)) {
				Object key = generateKey(context, CacheOperationExpressionEvaluator.NO_RESULT);
				Cache cache = context.getCaches().iterator().next();
				try {
					return wrapCacheValue(method, cache.get(key, () -> unwrapReturnValue(invokeOperation(invoker))));
				}
				catch (Cache.ValueRetrievalException ex) {
					// The invoker wraps any Throwable in a ThrowableWrapper instance so we
					// can just make sure that one bubbles up the stack.
					throw (CacheOperationInvoker.ThrowableWrapper) ex.getCause();
				}
			}
			else {
				// No caching required, only call the underlying method
				return invokeOperation(invoker);
			}
		}

		// sync=false的情况，走这里~~~

		
		// Process any early evictions  beforeInvocation=true的会在此处最先执行~~~
		
		// 最先处理@CacheEvict注解~~~真正执行的方法请参见：performCacheEvict
		// context.getCaches()拿出所有的caches，看看是执行cache.evict(key);方法还是cache.clear();而已
		// 需要注意的的是context.isConditionPassing(result); condition条件此处生效，并且可以使用#result
		// context.generateKey(result)也能使用#result
		// @CacheEvict没有unless属性
		processCacheEvicts(contexts.get(CacheEvictOperation.class), true, CacheOperationExpressionEvaluator.NO_RESULT);

	
		// 执行@Cacheable  看看缓存是否能够命中
		Cache.ValueWrapper cacheHit = findCachedItem(contexts.get(CacheableOperation.class));

		// Collect puts from any @Cacheable miss, if no cached item is found
		List<CachePutRequest> cachePutRequests = new LinkedList<>();
		// 如果缓存没有命中，那就准备一个cachePutRequest
		// 因为@Cacheable首次进来肯定命中不了，最终肯定是需要执行一次put操作的~~~这样下次进来就能命中了呀
		if (cacheHit == null) {
			collectPutRequests(contexts.get(CacheableOperation.class), CacheOperationExpressionEvaluator.NO_RESULT, cachePutRequests);
		}

		Object cacheValue;
		Object returnValue;

		// 如果缓存命中了，并且并且没有@CachePut的话，也就直接返回了~~
		if (cacheHit != null && !hasCachePut(contexts)) {
			// If there are no put requests, just use the cache hit
			cacheValue = cacheHit.get();
			// wrapCacheValue主要是支持到了Optional
			returnValue = wrapCacheValue(method, cacheValue);
		} else { //到此处，目标方法就肯定是需要执行了的~~~~~
			// Invoke the method if we don't have a cache hit
			// 啥都不说，先invokeOperation执行目标方法，拿到方法的的返回值  后续在处理put啥的
			returnValue = invokeOperation(invoker);
			cacheValue = unwrapReturnValue(returnValue);
		}

		// Collect any explicit @CachePuts   explicit：明确的
		collectPutRequests(contexts.get(CachePutOperation.class), cacheValue, cachePutRequests);

		// Process any collected put requests, either from @CachePut or a @Cacheable miss
		for (CachePutRequest cachePutRequest : cachePutRequests) {
			// 注意：此处unless啥的生效~~~~
			// 最终执行cache.put(key, result);方法
			cachePutRequest.apply(cacheValue);
		}

		// Process any late evictions beforeInvocation=true的会在此处最先执行~~~  beforeInvocation=false的会在此处最后执行~~~
		// 所以中途若抛出异常，此部分就不会执行了~~~~
		processCacheEvicts(contexts.get(CacheEvictOperation.class), false, cacheValue);
		return returnValue;
	}


	// 缓存属性的上下文们。每个方法可以对应多个上下文~~~
	private class CacheOperationContexts {

		// 因为方法上可以标注多个注解  
		// 需要注意的是它的key是Class，而CacheOperation的子类也就那三个哥们而已~
		private final MultiValueMap<Class<? extends CacheOperation>, CacheOperationContext> contexts;
		// 是否要求同步执行，默认值是false
		private final boolean sync;

		public CacheOperationContexts(Collection<? extends CacheOperation> operations, Method method, Object[] args, Object target, Class<?> targetClass) {

			this.contexts = new LinkedMultiValueMap<>(operations.size());
			for (CacheOperation op : operations) {
				this.contexts.add(op.getClass(), getOperationContext(op, method, args, target, targetClass));
			}

			// sync这个属性虽然不怎么使用，但determineSyncFlag这个方法可以看一下
			this.sync = determineSyncFlag(method);
		}

		public Collection<CacheOperationContext> get(Class<? extends CacheOperation> operationClass) {
			Collection<CacheOperationContext> result = this.contexts.get(operationClass);
			return (result != null ? result : Collections.emptyList());
		}
		public boolean isSynchronized() {
			return this.sync;
		}


		// 因为只有@Cacheable有sync属性，所以只需要看CacheableOperation即可
		private boolean determineSyncFlag(Method method) {
			List<CacheOperationContext> cacheOperationContexts = this.contexts.get(CacheableOperation.class);
			if (cacheOperationContexts == null) {  // no @Cacheable operation at all
				return false;
			}
			
			boolean syncEnabled = false;
			// 单反只要有一个@Cacheable的sync=true了，那就为true  并且下面还有检查逻辑
			for (CacheOperationContext cacheOperationContext : cacheOperationContexts) {
				if (((CacheableOperation) cacheOperationContext.getOperation()).isSync()) {
					syncEnabled = true;
					break;
				}
			}

			// 执行sync=true的检查逻辑
			if (syncEnabled) {
				// 人话解释：sync=true时候，不能还有其它的缓存操作 也就是说@Cacheable(sync=true)的时候只能单独使用
				if (this.contexts.size() > 1) {
					throw new IllegalStateException("@Cacheable(sync=true) cannot be combined with other cache operations on '" + method + "'");
				}
				// 人话解释：@Cacheable(sync=true)时，多个@Cacheable也是不允许的
				if (cacheOperationContexts.size() > 1) {
					throw new IllegalStateException("Only one @Cacheable(sync=true) entry is allowed on '" + method + "'");
				}

				// 拿到唯一的一个@Cacheable
				CacheOperationContext cacheOperationContext = cacheOperationContexts.iterator().next();
				CacheableOperation operation = (CacheableOperation) cacheOperationContext.getOperation();

				// 人话解释：@Cacheable(sync=true)时，cacheName只能使用一个
				if (cacheOperationContext.getCaches().size() > 1) {
					throw new IllegalStateException("@Cacheable(sync=true) only allows a single cache on '" + operation + "'");
				}
				// 人话解释：sync=true时，unless属性是不支持的~~~并且是不能写的
				if (StringUtils.hasText(operation.getUnless())) {
					throw new IllegalStateException("@Cacheable(sync=true) does not support unless attribute on '" + operation + "'");
				}
				return true; // 只有校验都通过后，才返回true
			}
			return false;
		}
	}
	...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328

以上，拦截器实现了Spring Cache处理注解缓存的执行的核心步骤，个人建议上述代码可多读几遍，其义自见。

处理缓存注解的步骤总结

Spring Cache是Spring框架的核心模块之一，不可谓不重要。用了好几篇文章专门来讲解使用、分析原理。下面按照正常的思路，我把Spring处理的步骤总结如下：

1. CacheOperation封装了@CachePut、@Cacheable、@CacheEvict（下称三大缓存注解）的属性信息，以便于拦截的时候能直接操作此对象来执行逻辑。
   1. 解析三大注解到CacheOperation的过程是由CacheAnnotationParser完成的
2. CacheAnnotationSource代表缓存属性源，非常非常重要的一个概念。它提供接口方法来获取目标方法的CacheOperation集合。由上可知，这个具体工作是委托给CacheAnnotationParser去完成的
3. BeanFactoryCacheOperationSourceAdvisor它代表增强器，至于需要增强哪些类呢？？？就是看有没有存在CacheOperation属性的方法
4. CacheInterceptor实现了MethodInterceptor接口，在Spring AOP中实现对执行方法的拦截。在调用invoke执行目标方法前后，通过CacheAnnotationSource获取到方法所有的缓存操作属性，从而一个个的执行
5. 执行的时候，每一个CacheOperation最后被封装成了CacheOperationContext，而CacheOperationContext最终通过CacheResolver解析出缓存对象Cache（可能是多个）
6. 最后最后最后，CacheInterceptor调用其父类AbstractCacheInvoker执行对应的doPut / doGet / doEvict / doClear 等等。（可以处理执行异常）

CacheProxyFactoryBean：手动实现Cache功能

其实ProxyFactoryBean的设计模式在Spring AOP中已经非常不陌生了：【小家Spring】面向切面编程Spring AOP创建代理的方式：ProxyFactoryBean、ProxyFactory、AspectJProxyFactory（JDK Proxy和CGLIB）

如下截图，Spring内有非常多的xxxProxyFactoryBean的实现：

如果说把@EnableCaching称为自动模式的话，那使用CacheProxyFactoryBean就完全是手动档。话不多说，此处给个使用Demo就收场了：

@Configuration
public class RootConfig {

    @Bean
    public CacheProxyFactoryBean cacheProxyFactoryBean() {
        CacheProxyFactoryBean proxyFactoryBean = new CacheProxyFactoryBean();
        // 使用AnnotationCacheOperationSource来识别三大注解缓存
        proxyFactoryBean.setCacheOperationSources(new AnnotationCacheOperationSource());

        // 设置需要代理的目标类
        CacheDemoService cacheDemoService = new CacheDemoServiceImpl();
        proxyFactoryBean.setTarget(cacheDemoService);
        //proxyFactoryBean.setProxyInterfaces();

        // 设置个性化的一些东西
        CacheManager cacheManager = new ConcurrentMapCacheManager();
        proxyFactoryBean.setCacheManager(cacheManager);
        //proxyFactoryBean.setKeyGenerator();
        //proxyFactoryBean.setCacheResolver();

        return proxyFactoryBean;
    }

}


//@Service // 因为使用了CacheProxyFactoryBean手动额皮质，此处请不要再被扫描进去，否则容器内就出现两个这样的Bean了
public class CacheDemoServiceImpl implements CacheDemoService {

    @Cacheable(cacheNames = "demoCache", key = "#id")
    @Override
    public Object getFromDB(Integer id) {
        System.out.println("模拟去db查询~~~" + id);
        return "hello cache...";
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

测试：

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {RootConfig.class, CacheConfig.class})
public class TestSpringBean {

    @Autowired
    private CacheDemoService cacheDemoService;

    @Test
    public void test1() {
        cacheDemoService.getFromDB(1);
        cacheDemoService.getFromDB(1);
    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

打印结果：

模拟去db查询~~~1
1

只输出一套日志：缓存生效

此示例中@EnableCaching可不是打开状态哦，但我们依然能够使用手动档让缓存生效。
使用手动档，我们可以很方便的使用NameMatchCacheOperationSource来根据方法名匹配~~~

---

缓存注解使用案例

关于缓存注解的常规使用案例，我觉得本文没有必要介绍。
接下来主要讲解一些特殊的使用：

若方法返回值为null，还会缓存吗？

比如上例返回值改为null：

@Service
public class CacheDemoServiceImpl implements CacheDemoService {

    @Cacheable(cacheNames = "demoCache", key = "#id")
    @Override
    public Object getFromDB(Integer id) {
        System.out.println("模拟去db查询~~~" + id);
        //return "hello cache...";
        return null;
    }
}
1
2
3
4
5
6
7
8
9
10
11

执行单测：

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {RootConfig.class, CacheConfig.class})
public class TestSpringBean {
    @Autowired
    private CacheDemoService cacheDemoService;
    @Autowired
    private CacheManager cacheManager;

    @Test
    public void test1() {
        cacheDemoService.getFromDB(1);
        cacheDemoService.getFromDB(1);

        System.out.println("----------验证缓存是否生效----------");
        Cache cache = cacheManager.getCache("demoCache");
        System.out.println(cache);
        System.out.println(cache.get(1, String.class));
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

结果打印：

模拟去db查询~~~1
----------验证缓存是否生效----------
org.springframework.cache.concurrent.ConcurrentMapCache@15f2eda3
null
1
2
3
4

结论是：默认情况下，返回值是null也是会缓存的（第二次过来就不会再查询了）。通过一个断点会更清晰：

但假如修改缓存注解如下：

// 注意：unless 是非的意思
@Cacheable(cacheNames = "demoCache", key = "#id",unless = "#result == null")
1
2

运行打印如下：

模拟去db查询~~~1
模拟去db查询~~~1
----------验证缓存是否生效----------
org.springframework.cache.concurrent.ConcurrentMapCache@6a282fdd
null
1
2
3
4
5

查了两次DB，证明此时返回null就不会再缓存了，unless生效。

倘若修改配置如下：

    @Bean
    public CacheManager cacheManager() {
        ConcurrentMapCacheManager cacheManager = new ConcurrentMapCacheManager();
        cacheManager.setAllowNullValues(false);
        return cacheManager;
    }
1
2
3
4
5
6

运行则报错：

java.lang.IllegalArgumentException: Cache 'demoCache' is configured to not allow null values but null was provided
1

一般情况下，不建议这么设置，因为一般都是允许缓存null值的。

@Cacheable注解sync=true的效果

在多线程环境下，某些操作可能使用相同参数同步调用（相同的key）。默认情况下，缓存不锁定任何资源，可能导致多次计算，而违反了缓存的目的。对于这些特定的情况，属性 sync 可以指示底层将缓存锁住，使只有一个线程可以进入计算，而其他线程堵塞，直到返回结果更新到缓存中（Spring4.3提供的）。

下面给个例子直接看看效果就成：

@Cacheable(cacheNames = "demoCache", key = "#id")
1

测试Demo（多线程）：

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = {RootConfig.class, CacheConfig.class})
public class TestSpringBean {

    @Autowired
    private CacheDemoService cacheDemoService;

    @Test
    public void test1() throws InterruptedException {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                cacheDemoService.getFromDB(1);
            }).start();
        }

        // 保证main线程不要这么快结束（否则没有日志结果的~~~）
        TimeUnit.SECONDS.sleep(10);

    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

打印结果：

模拟去db查询~~~1
模拟去db查询~~~1
模拟去db查询~~~1
模拟去db查询~~~1
模拟去db查询~~~1
1
2
3
4
5

打印可能5次、可能6次不确定。但是若我们sync=true了呢？

@Cacheable(cacheNames = "demoCache", key = "#id", sync = true)
1

再次运行测试打印结果如下：

模拟去db查询~~~1
1

永远只会打印一次。 所以在高并发环境下，我个人是十分建议开启此同步开关的，至于非高并发，无所谓啦~

注解可重复标注吗？

因为源码都分析了，所以此处看结论即可。

    @CachePut(cacheNames = "demoCache", key = "#id") // 不同的注解可以标注多个
    //@Cacheable(cacheNames = "demoCache", key = "#id") // 相同注解标注两个是不行的 因为它并不是@Repeatable的
    @Cacheable(cacheNames = "demoCache", key = "#id")
    @Override
    public Object getFromDB(Integer id) {
        System.out.println("模拟去db查询~~~" + id);
        return "hello cache...";
    }
1
2
3
4
5
6
7
8

不同的注解可以标注多个，且都能生效。若需要相同注解标注多个等更复杂的场景，推荐使用@Caching注解

如何给缓存注解设置专用的key生成器、缓存管理器等等

标准写法是这样的：

@EnableCaching
@Configuration
public class CacheConfig implements CachingConfigurer {
    @Override
    public CacheResolver cacheResolver() {
        return null;
    }
    @Override
    public KeyGenerator keyGenerator() {
        return null;
    }
    @Override
    public CacheErrorHandler errorHandler() {
        return null;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

实现对应的方法，可以new一个对象返回，也可以用容器内的。

大多数情况下我们都不需要特别的指定缓存注解使用的管理器，因为它自己会去容器里找。 但是，但是，但是当你使用了多套缓存时，我还是建议显示的指定的。

总结

本篇文章相对较长，因为从原理处深度分析了Spring Cache的执行过程，希望能帮助到大家做到心里有数，从而更加健康的书写代码和扩展功能。

关于缓存注解这块，我相信很多人都有一个痛点：注解并不支持设置过期时间。其实我想说，如果你看了上篇文章就知道，这个Spring它做不了，因为它并没有对Expire进行抽象。
但是Spring做不了不代表我们自己做不了，因此有兴趣的同学可以在此基础上，扩展出可以自定义超时时间的能力~~~~

---

关注A哥