Ehcache注解核心逻辑源码学习

Ehcache支持方法注解方式管理缓存,使代码的侵入性很小。最常用的Ehcache注解是@Cacheable、@CacheEvict、@CachePut

本文通过分析源码整理了这几个注解的实现逻辑和关系,并指出一些组合使用时的限制

 

1注解类源码

1.1@Cacheable

/**
 * Cacheable注解缓存方法(或类的所有方法)返回值,缓存Key是方法本身和参数的组合签名
 * 通俗说就是同样的参数调用两次,不会重复执行方法,也是缓存最朴素的动机
 */
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Cacheable {

	/**
	 * 缓存bean的名称,可在xml中定义,支持多个。必填属性
	 */
	String[] value();

	/**
	 * SpEL语法表述的缓存键值,默认空表示所有参数的联合签名
	 * Exp "#arg1"
	 */
	String key() default "";

	/**
	 * SpEL语法表述的缓存命中条件,默认空没有条件
	 * Exp "#arg1>0"
	 * condition是在方法调用前判断的,只有命中条件的调用才会触发缓存逻辑,否则方法会被直接调用
	 * 注意condition只判断是否启用缓存,而不是是否入缓存
	 * 注意如果条件中带有返回值#result,则无论改调用是否已经在缓存中(通过其他途径),方法仍会被调用,这个后续会说到
	 * 因此@Cacheble注解的condition条件实际上不能带#result,否则这个缓存相当于失效
	 * 注意如果方法抛异常,也不会入缓存(因为没有返回值)
	 */
	String condition() default "";

	/**
	 * SpEL语法表述的缓存否决条件,否决指不入缓存。默认空没有条件
	 * unless是在方法调用后判断的,因此可以拿到返回值#result,unless判断为true时结果不入缓存
	 */
	String unless() default "";
}

 

1.2@CachePut

缓存更新注解,不会影响方法调用,并且返回值会更新到缓存。用于缓存的刷新。同一方法@Cacheable和@CachePut不应同时使用

参数与@Cacheable一样,不同点:

condition命中表示更新生效,否则返回值不会更新,方法仍会调用

unless命中表示否决更新,方法仍然调用

由于方法始终调用,单独使用@CachePut时,condition和unless的逆是等价的

 

1.3@CacheEvict

缓存清空注解,不会影响方法调用,只影响数据出缓存,参数异同:

key参数是有默认值的,默认空表示任何参数调用都清缓存

condition命中表示不清除缓存

没有unless参数

	/**
	 * true表示任何调用都清空所有缓存,如设为true,则key参数失效)
	 */
	boolean allEntries() default false;

	/**
	 * true表示方法调用前清缓存,不受返回值及抛异常影响,这是唯一一个在异常情况下仍然生效的注解
	 * false表示方法调用后清缓存,如果抛异常则不清缓存,如命中@Cacheable也不清缓存
	 */
	boolean beforeInvocation() default false;

  

2.调用栈

 

 

所以Ehcache用的标准spring aop动态代理实现方法拦截,所以Ehcache注解只能加在Spring托管的bean方法上,这一点对于Spring注解都是一样的

核心逻辑在CacheInterceptor这个类(及其父类CacheAspectSupport)

 

3 CacheInterceptor源码(删掉了一些无关紧要的代码,下同)

 

/**
 * 标准的Aop MethodInterceptor实现缓存逻辑,物理缓存为org.springframework.cache.Cache
 * 缓存逻辑主要在父类中
*/
public class CacheInterceptor extends CacheAspectSupport implements MethodInterceptor, Serializable {

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

		// 父类中声明的内嵌接口,实现就是触发invocation原始方法执行
		// 之所以要封装一层接口是为了Spring的动态代理可以嵌套,因为cglib代理后是final类,无法直接二次代理
		Invoker aopAllianceInvoker = new Invoker() {
			public Object invoke() {
				try {
					return invocation.proceed();
				} catch (Throwable ex) {
					throw new ThrowableWrapper(ex);
				}
			}
		};

		// 主方法就是触发父类的execute
		try {
			return execute(aopAllianceInvoker, invocation.getThis(), method, invocation.getArguments());
		} catch (ThrowableWrapper th) {
			throw th.original;
		}
	}
}

 

 

4 CacheAspectSupport源码

4.1 主要属性

 

	// 常量
	private static final String CACHEABLE = "cacheable";
	private static final String UPDATE = "cacheupdate";
	private static final String EVICT = "cacheevict";

	// SpEL语言解析器,处理condition、key、unless等表达式
	private final ExpressionEvaluator evaluator = new ExpressionEvaluator();
	// 物理缓存容器
	private CacheManager cacheManager;
	// 逻辑缓存容器,此处实现类为AnnotationCacheOperationSource,主要属性为Map<Object, Collection<CacheOperation>> attributeCache
// Key是方法签名,CacheOperation可以理解为Ehcache注解的对象化类
// 整个cacheOperationSource封装了全局的缓存注解分布状态
	private CacheOperationSource cacheOperationSource;
	// 缓存Key生成器
	private KeyGenerator keyGenerator = new DefaultKeyGenerator();

4.2.主方法

 

 

	protected Object execute(Invoker invoker, Object target, Method method, Object[] args) {

		// 这里是为了获取被代理的原始类,也就是@Component的Bean本类
		// 此处会剥离其他的Aop增强类以及cglib代理子类
		Class<?> targetClass = AopProxyUtils.ultimateTargetClass(target);
		if (targetClass == null && target != null) {
			targetClass = target.getClass();
		}
		// 此处获取具体方法的缓存设置,可以理解为method上打的注解全集
		Collection<CacheOperation> cacheOp = getCacheOperationSource().getCacheOperations(method, targetClass);

		// 如果没有打注解,就是普通方法,直接proceed就行了
		if (!CollectionUtils.isEmpty(cacheOp)) {
			// 此步对注解类进一步分类封装,Key就是固定的3个常量,CacheOperationContext是内嵌类,封装了注解本身和物理Cache及相应方法
			Map<String, Collection<CacheOperationContext>> ops = createOperationContext(cacheOp, method, args, target, targetClass);
			// 以下开始为核心逻辑,按一定顺序处理各类缓存注解,此部分逻辑直接影响到注解的使用方式和组合效果
			// 首先处理@CacheEvict的beforeInvoke。这个方法和inspectAfterCacheEvicts实际只会生效一个
			// 此处是唯一在方法调用前可能对缓存执行写操作的方法
			inspectBeforeCacheEvicts(ops.get(EVICT));
			// 然后是@Cacheable,这个CacheStatus封装了返回值(缓存or调用方法)和需要更新的缓存值
			// 注意此方法还不会执行写缓存操作,而是先记录在status里面,最后一起更新
			CacheStatus status = inspectCacheables(ops.get(CACHEABLE));
			Object retVal;
			// 然后是@CachePut,这个注解不会影响方法调用
			// 这个Map封装了所有待更新的key,注意key可能有多个,retVal只会有一个
			Map<CacheOperationContext, Object> updates = inspectCacheUpdates(ops.get(UPDATE));

			// 最终处理之前的结果
			if (status != null) {
				// 如果@Cacheable有未命中缓存的调用,添加到待更新的key集合,注意此处仍未执行写缓存,也没有调用方法
				if (status.updateRequired) {
					updates.putAll(status.cacheUpdates);
				} else {
					// 如果命中了缓存,直接返回缓存的数据,整个处理结束
					// 注意一旦命中缓存,除了@CacheEvict(beforeInvocation=true),不会对缓存进行其他任何写操作
					return status.retVal;
				}
			}

			// 走到这里,说明没有@Cacheable护照缓存没有命中,于是需要调用方法proceed
			retVal = invoker.invoke();
			// 拿到返回值后,再处理@CacheEvict(beforeInvoke=false),逻辑基本与inspectBeforeCacheEvicts一样,只是condition可以带#result
			inspectAfterCacheEvicts(ops.get(EVICT), retVal);
			// 最后统一写缓存
			if (!updates.isEmpty()) {
				// 此处会解析@CachePut和@Cacheble的unless属性生效,会判断是否命中unless,如命中则最终不会写缓存
				update(updates, retVal);
			}
			return retVal;
		}

		return invoker.invoke();
	}

  

 

4.3.Evict

 

	private void inspectBeforeCacheEvicts(Collection<CacheOperationContext> evictions) {
		// 调用前,没有返回值,所以返回值传ExpressionEvaluator.NO_RESULT标志位
		inspectCacheEvicts(evictions, true, ExpressionEvaluator.NO_RESULT);
	}

	private void inspectAfterCacheEvicts(Collection<CacheOperationContext> evictions, Object result) {
		inspectCacheEvicts(evictions, false, result);
	}

	// 实现方法,result为原始方法的返回值
	private void inspectCacheEvicts(Collection<CacheOperationContext> evictions, boolean beforeInvocation, Object result) {
		if (!evictions.isEmpty()) {
			for (CacheOperationContext context : evictions) {
				// 枚举每个@CacheEvict
				CacheEvictOperation evictOp = (CacheEvictOperation) context.operation;
				// 这个if根据beforeInvocation参数判断是方法调用前还是调用后生效
				if (beforeInvocation == evictOp.isBeforeInvocation()) {
					// 这个地方过滤condition是否命中,不命中的话注解无效
// 注意如果ExpressionEvaluator.NO_RESULT (beforeInvocation),且SpEL含有#result,这个条件是必不过的
// 所以在如果beforeInvocation,condition又写了#result,相当于没有写condition
					if (context.isConditionPassing(result)) {
						// 缓存key是lazy load的,第一个Cache操作的时候才生成
						Object key = null;
						for (Cache cache : context.getCaches()) {
							// 这个if就是@CacheEvict的allEntries参数
							if (evictOp.isCacheWide()) {
								cache.clear(); // 如果allEntries=true,清空整个缓存
							} else { // 否则就清除单个Key
								if (key == null) {
									key = context.generateKey();
								}
								cache.evict(key);
							}
						}
					}
				}
			}
		}
	}

 

 

4.4.Cache

	private CacheStatus inspectCacheables(Collection<CacheOperationContext> cacheables) {
		// 待写缓存的内容
		Map<CacheOperationContext, Object> cacheUpdates = new LinkedHashMap<CacheOperationContext, Object>(cacheables.size());
		boolean cacheHit = false;	// 是否命中缓存,如最终为true不调用方法proceed
		Object retVal = null;

		if (!cacheables.isEmpty()) {
			// 是否存在某个condition通过,同一方法不能打两个@Cacheable,这里多个可能是考虑到其他aop的情况
			boolean atLeastOnePassed = false; 
			for (CacheOperationContext context : cacheables) {
				// 过滤condition是否命中,不命中的话注解无效(会执行方法)
				// 注意如果condition含有#result,这个条件是必不过的,相当于注解失效
				if (context.isConditionPassing()) {
					atLeastOnePassed = true;
					Object key = context.generateKey();	// 生成缓存Key
					if (key == null) {
						throw new IllegalArgumentException("Null key returned for cache operation (maybe you " +
								"are using named params on classes without debug info?) " + context.operation);
					}
					// 记录所有关联的key,key可能有多个,value只会有一个
					cacheUpdates.put(context, key);
					// check whether the cache needs to be inspected or not (the method will be invoked anyway)
					if (!cacheHit) {		// 这个分支全方法只会进一次
						for (Cache cache : context.getCaches()) {
							Cache.ValueWrapper wrapper = cache.get(key);
							// 命中缓存 
							if (wrapper != null) { 
								retVal = wrapper.get();	// 这个分支全方法也只会进一次
								cacheHit = true;
								// 注意如果注册了多个缓存,只取第一个命中的值,而缓存顺序是不能指定的
								break;
							}
						}
					}
				}
			}

			// 返回,如果condition(全部)不通过,则返回null,相当于注解失效,否则返回结果
			if (atLeastOnePassed) {
				// 因为cacheHit是全局的,只要有一个缓存命中updateRequired就是false,其他缓存都不会刷新(即使有的值已经过期)
				// 如果全部没有命中,才会添加返回值到各个缓存
				return new CacheStatus(cacheUpdates, !cacheHit, retVal);
			}
		}

		return null;
	}

 

4.5.Put

	private Map<CacheOperationContext, Object> inspectCacheUpdates(Collection<CacheOperationContext> updates) {
		Map<CacheOperationContext, Object> cacheUpdates = new LinkedHashMap<CacheOperationContext, Object>(updates.size());
		if (!updates.isEmpty()) {
			for (CacheOperationContext context : updates) {
				if (context.isConditionPassing()) {		// condition通过
					Object key = context.generateKey();
					if (key == null) {
						throw new IllegalArgumentException("Null key returned for cache operation (maybe you " +
								"are using named params on classes without debug info?) " + context.operation);
					}
					// Put的逻辑很简单,通过condition就直接添加待更新的key,由上层统一写入
					cacheUpdates.put(context, key);
				}
			}
		}
		return cacheUpdates;
	}

 

5.一个应用场景

 

一个Redis的KV表,上层用Ehcache缓存

要求:Redis获取成功时,返回值入缓存;Redis获取失败时,不入缓存,下次调用仍然执行Redis查询

 

5.1正确方式

    @Override
    @Cacheable(value = "myCache", key = "#key", unless = "#result<0")
    public short getActiveTime(String key) {
        String value = redisDriver.get(key);
        try {
            return Short.valueOf(value);
        } catch (Exception e) {
            return -1;
        }
    }

 

5.2错误的方式1

@Cacheable(value = "activeTimeCache", key = "#deviceSignature", condition="#result>=0")

 错误原因是condition是方法调用前校验,@Cacheable的condition中带有#result,则condition一定不成立,所以注解相当于失效

 

5.3错误的方式2

@CacheEvict(value = "activeTimeCache", key = "#deviceSignature", condition="#result<0")
@Cacheable(value = "activeTimeCache", key = "#deviceSignature")

此写法本意是先全部缓存,再删掉返回值<0的。但是根据之前的源码,@Cacheable的实际写操作要晚于@CacheEvict,所以-1还是会入缓存

以上这种方式如要生效也是可以的,需要做两层嵌套的Bean,把@CacheEvict加在外层方法上,这时候外层的inspectAfterCacheEvicts会晚于内层的update。当然为了缓存加一层嵌套是很不美观的。有了unless就不需要这样的方式了 

你可能感兴趣的:(ehcache)