接口方法上的注解无法被@Aspect声明的切面拦截的原因分析

转载自接口方法上的注解无法被@Aspect声明的切面拦截的原因分析

前言

在Spring中使用MyBatis的Mapper接口自动生成时，用一个自定义的注解标记在Mapper接口的方法中，再利用@Aspect定义一个切面，拦截这个注解以记录日志或者执行时长。但是惊奇的发现这样做之后，在Spring Boot 1.X(Spring Framework 4.x)中，并不能生效，而在Spring Boot 2.X(Spring Framework 5.X)中却能生效。

这究竟是为什么呢？Spring做了哪些更新产生了这样的变化？此文将带领你探索这个秘密。

案例

核心代码

@SpringBootApplicationpublic class Starter {public static void main(String[] args) {SpringApplication.run(DynamicApplication.class, args);}}@Servicepublic class DemoService {@AutowiredDemoMapper demoMapper;public List<Map<String, Object>> selectAll() {return demoMapper.selectAll();}}/*** mapper类*/@Mapperpublic interface DemoMapper {@Select("SELECT * FROM demo")@DemoList<Map<String, Object>> selectAll();}/*** 切入的注解*/@Target({ElementType.METHOD})@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface Demo {String value() default "";}/*** aspect切面，用于测试是否成功切入*/@Aspect@Order(-10)@Componentpublic class DemoAspect {@Before("@annotation(demo)")public void beforeDemo(JoinPoint point, Demo demo) {System.out.println("before demo");}@AfterDemo("@annotation(demo)")public void afterDemo(JoinPoint point, Demo demo) {System.out.println("after demo");}}

测试类

@RunWith(SpringRunner.class) @SpringBootTest(classes = Starter.class)public class BaseTest {@AutowiredDemoService demoService;@Testpublic void testDemo() {demoService.selectAll();} }

在Spring Boot 1.X中，@Aspect里的两个println都没有正常打印，而在Spring Boot 2.X中，都打印了出来。

调试研究

已知@Aspect注解声明的拦截器，会自动切入符合其拦截条件的Bean。这个功能是通过@EnableAspectJAutoProxy注解来启用和配置的(默认是启用的，通过AopAutoConfiguration)，由@EnableAspectJAutoProxy中的@Import(AspectJAutoProxyRegistrar.class)可知，@Aspect相关注解自动切入的依赖是AnnotationAwareAspectJAutoProxyCreator这个BeanPostProcessor。在这个类的postProcessAfterInitialization方法中打上条件断点：beanName.equals(“demoMapper”)

public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {if (bean != null) {// 缓存中尝试获取，没有则尝试包装Object cacheKey = getCacheKey(bean.getClass(), beanName);if (!this.earlyProxyReferences.contains(cacheKey)) {return wrapIfNecessary(bean, beanName, cacheKey);}}return bean;}

在wrapIfNecessary方法中，有自动包装Proxy的逻辑：

protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {// 如果是声明的需要原始Bean，则直接返回if (beanName != null && this.targetSourcedBeans.contains(beanName)) {return bean;}// 如果不需要代理，则直接返回if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {return bean;}// 如果是Proxy的基础组件如Advice、Pointcut、Advisor、AopInfrastructureBean则跳过if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {this.advisedBeans.put(cacheKey, Boolean.FALSE);return bean;}// Create proxy if we have advice.// 根据相关条件，查找interceptor，包括@Aspect生成的相关Interceptor。// 这里是问题的关键点，Spring Boot 1.X中这里返回为空，而Spring Boot 2.X中，则不是空Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);if (specificInterceptors != DO_NOT_PROXY) {// 返回不是null，则需要代理this.advisedBeans.put(cacheKey, Boolean.TRUE);// 放入缓存Object proxy = createProxy(bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));// 自动生成代理实例this.proxyTypes.put(cacheKey, proxy.getClass());return proxy;}this.advisedBeans.put(cacheKey, Boolean.FALSE);return bean;}

调试发现，Spring Boot 1.X中specificInterceptors返回为空，而Spring Boot 2.X中则不是空，那么这里就是问题的核心点了，查看源码：

protected Object[] getAdvicesAndAdvisorsForBean(Class<?> beanClass, String beanName, TargetSource targetSource) {List<Advisor> advisors = findEligibleAdvisors(beanClass, beanName);if (advisors.isEmpty()) {// 如果是空，则不代理return DO_NOT_PROXY;}return advisors.toArray();}protected List<Advisor> findEligibleAdvisors(Class<?> beanClass, String beanName) {// 找到当前BeanFactory中的AdvisorList<Advisor> candidateAdvisors = findCandidateAdvisors();// 遍历Advisor，根据Advisor中的PointCut判断，返回所有合适的AdvisorList<Advisor> eligibleAdvisors = findAdvisorsThatCanApply(candidateAdvisors, beanClass, beanName);// 扩展advisor列表，这里会默认加入一个ExposeInvocationInterceptor用于暴露动态代理对象，之前文章有解释过extendAdvisors(eligibleAdvisors);if (!eligibleAdvisors.isEmpty()) {// 根据@Order或者接口Ordered排序eligibleAdvisors = sortAdvisors(eligibleAdvisors);}return eligibleAdvisors;}protected List<Advisor> findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> beanClass, String beanName) {ProxyCreationContext.setCurrentProxiedBeanName(beanName);try {// 真正的查找方法  return AopUtils.findAdvisorsThatCanApply(candidateAdvisors, beanClass);}finally {ProxyCreationContext.setCurrentProxiedBeanName(null);}}

这里的核心问题在于AopUtils.findAdvisorsThatCanApply方法，这里的返回在两个版本是不一样的，由于这里代码过多就不贴上来了，说明下核心问题代码是这段：

// AopProxyUtils.javapublic static List<Advisor> findAdvisorsThatCanApply(List<Advisor> candidateAdvisors, Class<?> clazz) {// ... 省略for (Advisor candidate : candidateAdvisors) {if (canApply(candidate, clazz, hasIntroductions)) {eligibleAdvisors.add(candidate);}}// ... 省略}public static boolean canApply(Advisor advisor, Class<?> targetClass, boolean hasIntroductions) {if (advisor instanceof IntroductionAdvisor) {return ((IntroductionAdvisor) advisor).getClassFilter().matches(targetClass);}else if (advisor instanceof PointcutAdvisor) {// 对于@Aspect的切面，是这段代码在生效PointcutAdvisor pca = (PointcutAdvisor) advisor;return canApply(pca.getPointcut(), targetClass, hasIntroductions);}else {// It doesn't have a pointcut so we assume it applies.return true;}}

基本定位了问题点，看下最终调用的canApply方法，Spring Boot 1.X与2.X这里的代码是不一样的

Spring Boot 1.X中源码，即Spring AOP 4.X中源码

/*** targetClass是com.sun.proxy.$Proxy??即JDK动态代理生成的类* hasIntroductions是false，先不管*/public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {Assert.notNull(pc, "Pointcut must not be null");// 先判断class，这里两个版本都为trueif (!pc.getClassFilter().matches(targetClass)) {return false;}MethodMatcher methodMatcher = pc.getMethodMatcher();// 如果method是固定true，即拦截所有method，则返回true。这里当然为falseif (methodMatcher == MethodMatcher.TRUE) {// No need to iterate the methods if we're matching any method anyway...return true;}// 特殊类型，做下转换，Aspect生成的属于这个类型IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;if (methodMatcher instanceof IntroductionAwareMethodMatcher) {introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;}// 取到目标class的所有接口Set<Class<?>> classes = new LinkedHashSet<Class<?>>(ClassUtils.getAllInterfacesForClassAsSet(targetClass));// 再把目标calss加入遍历列表classes.add(targetClass);for (Class<?> clazz : classes) {Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);// 遍历每个类的每个方法，尝试判断是否matchfor (Method method : methods) {if ((introductionAwareMethodMatcher != null &&introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||methodMatcher.matches(method, targetClass)) {return true;}}}return false;}

Spring Boot 2.X中源码，即Spring AOP 5.X中源码

public static boolean canApply(Pointcut pc, Class<?> targetClass, boolean hasIntroductions) {Assert.notNull(pc, "Pointcut must not be null");if (!pc.getClassFilter().matches(targetClass)) {return false;}MethodMatcher methodMatcher = pc.getMethodMatcher();if (methodMatcher == MethodMatcher.TRUE) {// No need to iterate the methods if we're matching any method anyway...return true;}IntroductionAwareMethodMatcher introductionAwareMethodMatcher = null;if (methodMatcher instanceof IntroductionAwareMethodMatcher) {introductionAwareMethodMatcher = (IntroductionAwareMethodMatcher) methodMatcher;}Set<Class<?>> classes = new LinkedHashSet<>();// 这里与1.X版本不同，使用Jdk动态代理Proxy，先判断是否是Proxy，如果不是则加入用户Class，即被动态代理的class，以便查找真正的Class中是否符合判断条件// 因为动态代理可能只把被代理类的方法实现了，被代理类的注解之类的没有复制到生成的子类中，故要使用原始的类进行判断// JDK动态代理一样不会为动态代理生成类上加入接口的注解// 如果是JDK动态代理，不需要把动态代理生成的类方法遍历列表中，因为实现的接口中真实的被代理接口。if (!Proxy.isProxyClass(targetClass)) {classes.add(ClassUtils.getUserClass(targetClass));}classes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetClass));for (Class<?> clazz : classes) {Method[] methods = ReflectionUtils.getAllDeclaredMethods(clazz);for (Method method : methods) {// 比1.X版本少遍历了Proxy生成的动态代理类，但是遍历内容都包含了真实的接口，其实是相同的，为什么结果不一样呢？if ((introductionAwareMethodMatcher != null &&introductionAwareMethodMatcher.matches(method, targetClass, hasIntroductions)) ||methodMatcher.matches(method, targetClass)) {return true;}}}return false;}

调试信息图

上面的代码执行结果不同，但是区别只是少个动态代理生成的类进行遍历，为什么少一个遍历内容结果却是true呢？肯定是introductionAwareMethodMatcher或者methodMatcher的逻辑有改动，其中methodMatcher和introductionAwareMethodMatcher是同一个对象，两个方法逻辑相同。看代码：

/** AspectJExpressionPointcut.java* method是上面接口中遍历的方法，targetClass是目标class，即生成的动态代理class*/public boolean matches(Method method, @Nullable Class<?> targetClass, boolean beanHasIntroductions) {obtainPointcutExpression();Method targetMethod = AopUtils.getMostSpecificMethod(method, targetClass);ShadowMatch shadowMatch = getShadowMatch(targetMethod, method);// Special handling for this, target, @this, @target, @annotation// in Spring - we can optimize since we know we have exactly this class,// and there will never be matching subclass at runtime.if (shadowMatch.alwaysMatches()) {return true;}else if (shadowMatch.neverMatches()) {return false;}else {// the maybe caseif (beanHasIntroductions) {return true;}// A match test returned maybe - if there are any subtype sensitive variables// involved in the test (this, target, at_this, at_target, at_annotation) then// we say this is not a match as in Spring there will never be a different// runtime subtype.RuntimeTestWalker walker = getRuntimeTestWalker(shadowMatch);return (!walker.testsSubtypeSensitiveVars() ||(targetClass != null && walker.testTargetInstanceOfResidue(targetClass)));}}

这段代码在Spring Boot 1.X和2.X中基本是相同的，但是在AopUtils.getMostSpecificMethod(method, targetClass);这一句的执行结果上，两者是不同的，1.X返回的是动态代理生成的Class中重写的接口中的方法，2.X返回的是原始接口中的方法。

而在动态代理生成的Class中重写的接口方法里，是不会包含接口中的注解信息的，所以Aspect中条件使用注解在这里是拿不到匹配信息的，所以返回了false。

而在2.X中，因为返回的是原始接口的方法，故可以成功匹配。

问题就在于AopUtils.getMostSpecificMethod(method, targetClass)的逻辑：

// 1.Xpublic static Method getMostSpecificMethod(Method method, Class<?> targetClass) {// 这里返回了targetClass上的重写的method方法。Method resolvedMethod = ClassUtils.getMostSpecificMethod(method, targetClass);// If we are dealing with method with generic parameters, find the original method.return BridgeMethodResolver.findBridgedMethod(resolvedMethod);}// 2.Xpublic static Method getMostSpecificMethod(Method method, @Nullable Class<?> targetClass) {// 比1.X多了个逻辑判断，如果是JDK的Proxy，则specificTargetClass为null，否则取被代理的Class。Class<?> specificTargetClass = (targetClass != null && !Proxy.isProxyClass(targetClass) ?ClassUtils.getUserClass(targetClass) : null);// 如果specificTargetClass为空，直接返回原始method。// 如果不为空，返回被代理的Class上的方法Method resolvedMethod = ClassUtils.getMostSpecificMethod(method, specificTargetClass);// If we are dealing with method with generic parameters, find the original method.// 获取真实桥接的方法，泛型支持return BridgeMethodResolver.findBridgedMethod(resolvedMethod);}

至此原因已经完全明了，Spring在AOP的5.X版本修复了这个问题。

影响范围

原因已经查明，那么根据原因我们推算一下影响范围

Bean是接口动态代理对象时，且该动态代理对象不是Spring体系生成的，接口中的切面注解无法被拦截
Bean是CGLIB动态代理对象时，该动态代理对象不是Spring体系生成的，原始类方法上的切面注解无法被拦截。
可能也影响基于类名和方法名的拦截体系，因为生成的动态代理类路径和类名是不同的。

如果是Spring体系生成的，之前拿到的都是真实类或者接口，只有在生成动态代理后，才是新的类。所以在创建动态代理时，获取的是真实的类。

接口动态代理多见于ORM框架的Mapper、RPC框架的SPI等，所以在这两种情况下使用注解要尤为小心。

有些同学比较关心@Cacheable注解，放在Mapper中是否生效。答案是生效，因为@Cacheable注解中使用的不是@Aspect的PointCut，而是CacheOperationSourcePointcut，其中虽然也使用了getMostSpecificMethod来获取method，但是最终其实又从原始方法上尝试获取了注解：

// AbstractFallbackCacheOperationSource.computeCacheOperationsif (specificMethod != method) {//  Fallback is to look at the original methodopDef = findCacheOperations(method);if (opDef != null) {return opDef;}// Last fallback is the class of the original method.opDef = findCacheOperations(method.getDeclaringClass());if (opDef != null && ClassUtils.isUserLevelMethod(method)) {return opDef;}}

看似不受影响，其实是做了兼容。

可以参考后面的内容，有提到Spring相关的issue

解决方案

如何解决这个问题呢？答案是在Spring Boot 1.X中没有解决方案。。因为这个类太基础了，除非切换版本。

使用其他Aspect表达式也可以解决此问题，使用注解方式在1.X版本是无解的。

表达式参考如下链接：

Spring 之AOP AspectJ切入点语法详解（最全面、最详细。）

https://blog.csdn.net/zhengchao1991/article/details/53391244
Spring Aspect的Execution表达式

https://blog.csdn.net/lang_niu/article/details/51559994

本来以为在注解Demo中加入@Inherited可解决的，结果发现不行，因为这个@Inherited只在类注解有效，在接口中或者方法上，都是不能被子类或者实现类继承的，看这个@Inherited上面的注释

/*** Indicates that an annotation type is automatically inherited.  If* an Inherited meta-annotation is present on an annotation type* declaration, and the user queries the annotation type on a class* declaration, and the class declaration has no annotation for this type,* then the class's superclass will automatically be queried for the* annotation type.  This process will be repeated until an annotation for this* type is found, or the top of the class hierarchy (Object)* is reached.  If no superclass has an annotation for this type, then* the query will indicate that the class in question has no such annotation.** <p>Note that this meta-annotation type has no effect if the annotated* type is used to annotate anything other than a class.  Note also* that this meta-annotation only causes annotations to be inherited* from superclasses; annotations on implemented interfaces have no* effect.* 上面这句话说明了只在父类上的注解可被继承，接口上的都是无效的** @author  Joshua Bloch* @since 1.5*/@Documented@Retention(RetentionPolicy.RUNTIME)@Target(ElementType.ANNOTATION_TYPE)public @interface Inherited {}

扩展阅读

问题及可能的影响范围已经详细分析完了，下面我们好奇一下，这个核心问题类AopUtils.java的提交记录中，作者有写什么吗

AopUtils.java类GitHub页面

https://github.com/spring-projects/spring-framework/blob/master/spring-aop/src/main/java/org/springframework/aop/support/AopUtils.java

查看这个类的历史记录，注意Commits on Apr 3, 2018这个日期的提交，其中提到：

Consistent treatment of proxy classes and interfaces for introspection

Issue: SPR-16675

Issue: SPR-16677

针对proxy classes做了内省配置，相关issue是SPR-16677，我们看下这个issue。

Spring Framework/SPR-16677

https://jira.spring.io/browse/SPR-16677

这个issue详细描述了这次提交的原因及目的。

读者感兴趣的话可以详细的阅读。

注意AopUtils.java的最新提交，又做了一些优化，可以研究一下。

扩展知识

上面的示例代码依赖于数据库，现做一个模拟Mapper类的改进，可以直接无任何依赖的重现该问题：

已知Mybatis的Mapper接口是通过JDK动态代理生成的逻辑，而Mapper接口相关的Bean生成，是通过AutoConfiguredMapperScannerRegistrar自动注册到BeanFactory中的，注册进去的是MapperFactoryBean这个工厂Bean类型。

而MapperFactoryBean的getObject方法，则是通过getSqlSession().getMapper(this.mapperInterface)生成的，mapperInterfact是mapper接口。

底层是通过Configuration.getMapper生成的，再底层是mapperRegistry.getMapper方法，代码如下

public <T> T getMapper(Class<T> type, SqlSession sqlSession) {final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);if (mapperProxyFactory == null) {throw new BindingException("Type " + type + " is not known to the MapperRegistry.");}try {// 调用下面的方法生成代理实例return mapperProxyFactory.newInstance(sqlSession);} catch (Exception e) {throw new BindingException("Error getting mapper instance. Cause: " + e, e);}}public T newInstance(SqlSession sqlSession) {// 创建MapperProxy这个InvocationHandler实例final MapperProxy<T> mapperProxy = new MapperProxy<T>(sqlSession, mapperInterface, methodCache);return newInstance(mapperProxy);}protected T newInstance(MapperProxy<T> mapperProxy) {// 调用jdk动态代理生成实例，代理的InvocationHandler是MapperProxyreturn (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);}

可以看到底层是通过JDK动态代理Proxy生成的，InvocationHandler是MapperProxy类。

清楚原理之后，我们对上面的实例做下改造，把Mybatis的引用简化。

@Configurationpublic class DemoConfiguraion {@Beanpublic FactoryBean<DemoMapper> getDemoMapper() {return new FactoryBean<DemoMapper>() {@Overridepublic DemoMapper getObject() throws Exception {InvocationHandler invocationHandler = (proxy, method, args) -> {System.out.println("调用动态代理方法" + method.getName());return Collections.singletonList(new HashMap<String, Object>());};return (DemoMapper) Proxy.newProxyInstance(this.getClass().getClassLoader(), new Class[] {DemoMapper.class}, invocationHandler);}@Overridepublic Class<?> getObjectType() {return DemoMapper.class;}@Overridepublic boolean isSingleton() {return true;}};}}

上面的代码可达到与Mapper同样的效果，大家可以本地随便玩哈。

接口方法上的注解无法被@Aspect声明的切面拦截的原因分析相关推荐

java获取方法上的注解_Spring：使用Spring AOP时，如何获取目标方法上的注解
当使用spring AOP时,判断目标方法上的注解进行相关操作,如缓存,认证权限等自定义注解 packagecom.agent.annotation;importjava.lang.annotati ...
Spring之AOP系列--将方法上的注解做为切点(用@Around)
原文网址:Spring之AOP系列--将方法上的注解做为切点(用@Around)_IT利刃出鞘的博客-CSDN博客简介说明本文介绍Spring(SpringBoot)的AOP的用 ...
【IOC 控制反转】Android 事件依赖注入 ( 事件依赖注入具体的操作细节 | 获取 Activity 中的所有方法 | 获取方法上的注解 | 获取注解上的注解 | 通过注解属性获取事件信息 )
文章目录前言一.获取 Activity 中的所有方法二.获取方法上的注解三.获取注解上的注解四.通过注解属性获取相关事件信息前言 Android 依赖注入的核心就是通过反射获取类 / 方 ...
spring aop获取目标对象的方法对象（包括方法上的注解）(转)
这两天在学习权限控制模块.以前看过传智播客黎活明老师的巴巴运动网视频教程,里面就讲到权限控制的解决方案,当时也只是看看视频,没有动手实践,虽说看过几遍,可是对于系统中的权限控制还是很迷茫,所以借着这次 ...
SpringBoot @Async加在实现接口类的非接口方法上获取Bean异常
一.场景复现报错日志 *************************** APPLICATION FAILED TO START ***************************Descr ...
Java接口限速器---＞注解与反射，枚举，AOP拦截器，异常处理中心，Redis实战
前言注: 大家好我是妈妈的好大儿, 笔者联系方式 QQ:3302254385 微信:yxc3302254385 交个朋友! 创作不易,三连十分感谢!!! 封装缘由各位小伙伴们大家好!!,在平常的编 ...
dnf电信上不了联通服务器未响应,DNF未响应的原因分析与解决方法
在玩dnf时是否出现过电脑未响应的情况,这让很多玩家都苦恼不已,下面学习啦小编就为大家介绍一下具体的原因分析与解决方法吧,欢迎大家参考和学习. DNF未响应的原因分析: 第一种:内存使用率过低,电脑工 ...
springSecurity-oauth2默认用户身份验证转换器( 方法上的注解权限authorities)
springSecurity-oauth2默认用户身份验证转换器 package com.xy.tasty.mgr.security;import com.xy.common.verify.Asser ...
android studio clone 方法不能先用,Android Studio中使用git功能无法clone原因分析
最近在使用git的时候发现一个非常诡异的问题,我用cmd命令行可以进行clone,push,pull等操作时都可以完美的成功,但是换到Android Studio中进行这些与远程库的操作的时候,就是各 ...

接口方法上的注解无法被@Aspect声明的切面拦截的原因分析

接口方法上的注解无法被@Aspect声明的切面拦截的原因分析相关推荐

最新文章

热门文章