spring-AOP(二) 自动代理

下图是AOP自动代理的流程图

spring中已经定义了创建代理的工厂类 ProxyFactory，通过 ProxyFactory 创建代理，必须要一个被代理对象和一个增强Advisor列表

spring的动态代理实质就是对象创建完毕之后，查找筛选能够应用于该对象上的Advisor列表，然后调用ProxyFactory创建代理对象返回。

Spring中定义了 AbstractAutoProxyCreator 类用于实现自动代理。

从继承图可以看出该类实现了 BeanPostProcessor 接口，覆写了postProcessAfterInitialization 方法。spring的bean初始化完成后会遍历注册的所有BeanPostProcessor实现类对象，调用其postProcessAfterInitialization方法，该方法可以返回一个新的对象覆盖原有对象，在此spring提供一个创建代理并覆盖被代理对象的机会

遍历容器中注册的所有BeanPostProcessor，调用postProcessAfterInitialization方法，如果返回一个新的对象会覆盖掉原始对象注册到spring容器中

上面分析了AbstractAutoProxyCreator是实现自动代理的关键，那么在spring中如何配置一个AbstractAutoProxyCreator的实现类对象呢，spring又是如何根据配置注册该对象的

在spring中可以通过两种配置，启动自动代理

这两中方法最终都是向spring容器中注册了一个AnnotationAwareAspectJAutoProxyCreator实例，这样在spring初始化完对象后就可以调用AnnotationAwareAspectJAutoProxyCreator的postProcessAfterInitialization方法了

上面分析了spring是在何时何处开始创建代理的，解下来分析AbstractAutoProxyCreator进行自动代理的总体实现

在postProcessAfterInitialization方法中判断 被代理对象不为空，调用wrapIfNecessary判断是否对目标类进行代理

createProxy方法中通过ProxyFactory设置AOP配置，如被代理对象和Advisor列表，调用getProxy创建代理对象。

至此AbstractAutoProxyCreator完成了自动创建代理的总体实现，在该抽象类中没有实现获取Adviso列表r的功能，交由各个子类去实现。

分析完spring自动代理的整体实现，接下来看下AbstractAutoProxyCreator的子类AbstractAdvisorAutoProxyCreator是如何进行查找 Advisor、筛选Advisor、排序Advisor的。

AbstractAdvisorAutoProxyCreator实现了getAdvicesAndAdvisorsForBean方法，用于获取应用于目标类的Advisor列表

在findEligibleAdvisors方法定义了查找 Advisor、筛选Advisor、排序Advisor三步 *** 作

在spring中可以通过注册Advisor的bean来实现对目标类的增强代理。spring会筛选出容器中所有Advisor类型的bean，用于对容器中的对象进行增强代理，查找的功能由AbstractAdvisorAutoProxyCreator类实现

将查找功能委托给advisorRetrievalHelper(BeanFactoryAdvisorRetrievalHelperAdapter)实现，该方法的功能就是获取Advisor类型的bean对象返回

spring除了支持配置或者手动注册 Advisor类型的bean之外，还支持通过 @Aspect、@Before、@After等AOP注解来声明Advisor。Advisor的查找解析由子类AnnotationAwareAspectJAutoProxyCreator实现

在AnnotationAwareAspectJAutoProxyCreator的findCandidateAdvisors方法中，第一步首先调父类的方法获取到容器中注册的所有Advisor，然后再委托aspectJAdvisorsBuilder解析注解获取Advisor，然后合并两个结果返回

BeanFactoryAspectJAdvisorsBuilderbuildAspectJAdvisors方法解析AOP注解封装为Advisor对象。

spring定义了一个AspectJAdvisorFactory接口用于解析AOP的注解,接口主要定义了两个功能

AspectJAdvisorFactory的实现类ReflectiveAspectJAdvisorFactory提供了具体实现

调用getAdvisor方法，获取通知方法上的Pointcut表达式，如果在方法上未解析到Pointcut，则跳过，然后根据通知方法和对应Pointcut封装返回一个Advisor的实现类InstantiationModelAwarePointcutAdvisorImpl对象

解析获取通知方法的Pointcut表达式，在该方法中会过滤掉不带Aop注解的非通知型方法，判断一个方法是不是通知就是判断该方法是否声明了切点

最终封装返回的Advisor是InstantiationModelAwarePointcutAdvisorImpl类型，在该实现类的getAdvice方法会回调ReflectiveAspectJAdvisorFactory中的getAdvice方法，ReflectiveAspectJAdvisorFactory会根据通知方法上不同的注解，创建对应的Advice

回调ReflectiveAspectJAdvisorFactory中的getAdvice，策略创建对应的Advice实现类对象

获取到spring容器中所有的Advisor之后，再回到AbstractAdvisorAutoProxyCreator类中，接下来筛选能够应用到目标对象的Advisor。通过Advisor中的Pointcut的ClassFilter和MethodMatcher来对目标对象进行匹配。 在这个阶段的筛选，只要Advisor能应用到目标类型的任意一个方法上都会返回成功

接下来看AbstractAdvisorAutoProxyCreatorfindAdvisorsThatCanApply方法，将筛选的工作委托给AopUtils来实现

AopUtilsfindAdvisorsThatCanApply方法中遍历所有的Advisor，然后调用canApply方法判断是否符合，在当中会区分引介增强和切点增强，引介增强是类级别的，只需要根据切点的ClassFilter对目标类进行判断就行。

canApply方法中，通过Pointcut来进行匹配，引介增强IntroductionAdvisor直接根据其ClassFilter判断目标类型，PointcutAdvisor根据其中的Pointcut来进行筛选

Pointcut会首先使用ClassFilter对目标类型进行过滤。如果通过，再使用 MethodMatcher 校验 类中所有的方法，只要有一个方法匹配上，代表该Advisor符合条件。

在这里宁可多通过，也不要校验太严格，因为在代理类中具体方法执行的时候，还会再一次使用Pointcut进行校验。所以该方法中会获取目标类型的所有接口，判断接口中的方法，有一个符合也会返回true

当获取到目标类型上的所有Advisor后，还需要对Advisor进行排序。Advisor的顺序决定了通知方法的应用顺序。

Advisor的排序主要分为两种

接下来看下spring是怎么实现排序的

AbstractAdvisorAutoProxyCreatorsortAdvisors提供了基于Ordered的排序，由spring的AnnotationAwareOrderComparator统一处理Ordered实现类或者添加@Ordered注解类的排序

AspectJAwareAdvisorAutoProxyCreator覆写了父类的sortAdvisors方法，在基于Ordered排序基础上提供了同一切面下不同通知之间的排序，具体排序实现委托给了PartialOrder

至此完成Advisor的查找、筛选、排序。

在传统的web项目中，防止重复提交，通常做法是：后端生成一个唯一的提交令牌(uuid)，并存储在服务端。页面提交请求携带这个提交令牌，后端验证并在第一次验证后删除该令牌，保证提交请求的唯一性。

思路没有问题，但是需要前后端都稍加改动，如果在业务开发完再加这个的话，改动量未免有些大了。无需前端配合，纯后端处理，是最清爽的。设计思路如下：

自定义注解@RreventReSubmit标记所有Controller中的提交请求。通过AOP 对所有标记@RreventReSubmit的方法拦截。在业务方法执行前，获取当前用户的 token(或者JSessionId)+ 当前请求地址，作为一个唯一 KEY，去获取 Redis 分布式锁(如果此时并发获取，只有一个线程会成功获取锁)。当有请求调用接口时，到redis中查找相应的key，如果能找到，则说明重复提交，如果找不到，则执行 *** 作。业务方法执行后，释放锁。

切面类需要使用@Aspect和@Component这两个注解做标注。

在想要防止重复提交的接口上添加注解即可使用。

在Spring的AOP模块，一个主要的部分是代理对象的生成，可以通过ProxyFactoryBean来完成，它封装了主要代理对象的生成过程。在这个生成过程中，可以使用JDK的Proxy和CGLIB两种生成情况。

Tip: 什么是匿名类

即没有名称的类，其名称由Java编译器给出，一般为：外部类名称+$+匿名类顺序，名称也就是其他地方不能引用，不能实例化，只用一次，当然也就不能有构造器。

在ProxyFactoryBean中，需要为target目标对象生成Proxy代理对象，从而为AOP横切面的编织做好准备。从FactoryBean中获取对象，是以getObject()方法作为入口完成的。在该方法中，首先对通知器链进行初始化，封装了一系列的拦截器，这些拦截器都要从配置中读取，然后为代理对象的生成做好准备。在生成代理对象时，因为Spring中有singleton类型和prototype类型这两种不同的Bean,所以要对代理对象的生成做一个区分。

首先为Proxy代理对象配置Advisor链，在initializeAdvisorChain()方法中执行。

在该方法中它会首先通过thisadvisorChainInitialized来判断通知器链是否已经初始化了，如果已经初始化了，就直接返回。其他情况下，通过 thisinterceptorNames 来要添加的通知器名，然后通过该名从IOC容器中取得的通知器加入到拦截器链中。

生成singleton的代理对象在getSingletonInstance()中完成

如果它还没有被创建，则lazily creating

在Spring代理目标target时，其实并不是直接创建一个目标target的对象实例的，而是通过一个TargetSource类型的对象对目标target进行封装，Spring Aop获取目标对象始终是通过 TargetSourcegetTarget() 方法进行的。

proxy（代理对象）代理的不是target,而是TargetSource

那么问题来了:为什么SpringAOP代理不直接代理target,而需要通过代理TargetSource(target的来源,其内部持有target),间接代理target呢

通常情况下,一个proxy(代理对象)只能代理一个target,每次方法调用的目标也是唯一固定的target。但是,如果让proxy代理TargetSource,可以使得每次方法调用的target实例都不同(当然也可以相同,这取决于TargetSource实现)。这种机制使得方法调用变得灵活,可以扩展出很多高级功能,如:target pool(目标对象池)、hot swap(运行时目标对象热替换),等等。

Spring内置了多种TargetSource

监听调用AdvisedSupportListener实现类的activated方法

具体的代理对象的生成，是在ProxyFactoryBean的基类AdvisedSupport的实现中借助AopProxyFactory完成的，这个代理对象要么从JDK中生成，要么借助CGLIB获得。

这个AopProxyFactory是在初始化函数中定义的，使用的是DefaultAopProxyFactor。

如果targetClass是接口类，使用JDK来生成Proxy

如果不是接口类要生成Proxy,那么使用CGLIB来生成。

接下来分别介绍两种不同的方式来产生AopProxy代理对象

首先从advised对象中取得代理对象的代理接口配置，然后调用Proxy的newProxyInstance方法，得到最终的Proxy代理对象。

在生成代理对象时，需要指明三个参数，类加载器，代理接口和Proxy回调方法所在的对象。

在回调方法所在对象中，需要实现InvocationHandler接口，它定义了invoke方法，

对于JdkDynamimcAopProxy，它本身实现了InvocationHandler接口和invoke方法，这个invoke方法是Proxy代理对象的回调方法。

在该篇文章中就不讲解了，感兴趣的可以百度搜索。

注：本文大多数是对《Spring技术内幕》的阅读整理。

1、ioc原理：

在传统的实现中，由程序内部代码来控制组件之间的关系。需要使用new关键字来实现两个组件之间关系的组合，这种实现方式会造成组件之间耦合。IoC很好地解决了该问题，它将实现组件间关系从程序内部提到外部容器，也就是说由容器在运行期将组件间的某种依赖关系动态注入组件中。

对象A依赖于对象B,当对象A需要用到对象B的时候，IoC容器就会立即创建一个对象B送给对象A。IoC容器就是一个对象制造工厂，需要什么，它会给提供，直接使用即可，而不用考虑所用的东西是如何制成的，也不用考虑最后是怎么被销毁的，这一切全部由IOC容器包办。

2、aop原理：

AOP将业务逻辑组件和切面类都加入到容器中，负责在业务逻辑运行的时候将日志进行打印，切面类负责动态感知MathCalculatordiv运行到哪里然后执行。通过＠Aspect通知注解给切面类的目标方法标注何时何地运行。

在程序创建之前会根据切入点表达式对增强器进行一一匹配，最终拿到所有的增强器。创建代理对象过程中，会先创建一个代理工厂，获取到所有的增强器（通知方法），将这些增强器和目标类注入代理工厂，再用代理工厂创建对象。

扩展资料：

AOP的组成：

1、方面（Aspect）：一个关注点的模块化，这个关注点实现可能另外横切多个对象。事务管理是J2EE应用中一个很好的横切关注点例子。方面用Spring的Advisor或拦截器实现。

2、连接点（Joinpoint）：程序执行过程中明确的点，如方法的调用或特定的异常被抛出。

3、通知（Advice）：在特定的连接点，AOP框架执行的动作。各种类型的通知包括“around”、“before”和“throws”通知。通知类型将在下面讨论。许多AOP框架包括Spring都是以拦截器做通知模型，维护一个“围绕”连接点的拦截器链。

4、切入点（Pointcut）：指定一个通知将被引发的一系列连接点的集合。AOP框架必须允许开发者指定切入点：例如，使用正则表达式。

5、引入（Introduction）：添加方法或字段到被通知的类。Spring允许引入新的接口到任何被通知的对象。Spring中要使用Introduction,可有通过DelegatingIntroductionInterceptor来实现通知，通过DefaultIntroductionAdvisor来配置Advice和代理类要实现的接口

6、目标对象（Target Object）：包含连接点的对象。也被称作被通知或被代理对象。POJO

7、AOP代理（AOP Proxy）：AOP框架创建的对象，包含通知。在Spring中，AOP代理可以是JDK动态代理或者CGLIB代理。

8、织入（Weaving）：组装方面来创建一个被通知对象。这可以在编译时完成（例如使用AspectJ编译器），也可以在运行时完成。Spring和其他纯Java AOP框架一样，在运行时完成织入。

1 IoC，（Inverse of Control）控制反转，其包含两个内容：其一是控制，其二是反转。在程序中，被调用类的选择控制权从调用它的类中移除，转交给第三方裁决。这个第三方指的就是Spring的容器。IoC另解，依赖注入（Dependency Injection），调用类对被调用类的依赖关系由第三方注入，以移除调用类对被调用类的引用。

2 aop，面向切面编程(也叫面向方面)：Aspect Oriented Programming(AOP),是目前软件开发中的一个热点，也是Spring框架中的一个重要内容。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。

3 AOP是OOP的延续，是（Aspect Oriented Programming）的缩写，意思是面向切面（方面）编程。主要的功能是：日志记录，性能统计，安全控制，事务处理，异常处理等等。

4 主要的意图是：将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非指导业务逻辑的方法中，进而改 变这些行为的时候不影响业务逻辑的代码。

扩展资料：

IoC是一个很大的概念,可以用不同的方式实现。其主要形式有两种：

依赖查找：容器提供回调接口和上下文条件给组件。EJB和Apache Avalon 都使用这种方式。这样一来，组件就必须使用容器提供的API来查找资源和协作对象，仅有的控制反转只体现在那些回调方法上（也就是上面所说的 类型1）：容器将调用这些回调方法，从而让应用代码获得相关资源。

依赖注入：组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。容器全权负责的组件的装配，它会把符合依赖关系的对象通过JavaBean属性或者构造函数传递给需要的对象。通过JavaBean属性注射依赖关系的做法称为设值方法注入(Setter Injection)；将依赖关系作为构造函数参数传入的做法称为构造器注入（Constructor Injection）

实现数据访问层

数据访问层有两个目标。第一是将数据库引擎从应用中抽象出来，这样就可以随时改变数据库—比方说，从微软SQL变成Oracle。不过在实践上很少会这么做，也没有足够的理由未来使用实现数据访问层而进行重构现有应用的努力。

第二个目标是将数据模型从数据库实现中抽象出来。这使得数据库或代码开源根据需要改变，同时只会影响主应用的一小部分——数据访问层。这一目标是值得的，为了在现有系统中实现它进行必要的重构。

模块与接口重构

依赖注入背后的一个核心思想是单一功能原则（single responsibility principle）。该原则指出，每一个对象应该有一个特定的目的，而应用需要利用这一目的的不同部分应当使用合适的对象。这意味着这些对象在系统的任何地方都可以重用。但在现有系统里面很多时候都不是这样的。

随时增加单元测试

把功能封装到整个对象里面会导致自动测试困难或者不可能。将模块和接口与特定对象隔离，以这种方式重构可以执行更先进的单元测试。按照后面再增加测试的想法继续重构模块是诱惑力的，但这是错误的。

使用服务定位器而不是构造注入

实现控制反转不止一种方法。最常见的办法是使用构造注入，这需要在对象首次被创建是提供所有的软件依赖。然而，构造注入要假设整个系统都使用这一模式，这意味着整个系统必须同时进行重构。这很困难、有风险，且耗时。

AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。

而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。

上面的陈述可能过于理论化，举个简单的例子，对于“雇员”这样一个业务实体进行封装，自然是OOP/OOD的任务，我们可以为其建立一个“Employee”类，并将“雇员”相关的属性和行为封装其中。而用AOP设计思想对“雇员”进行封装将无从谈起。

同样，对于“权限检查”这一动作片断进行划分，则是AOP的目标领域。而通过OOD/OOP对一个动作进行封装，则有点不伦不类。

换而言之，OOD/OOP面向名词领域，AOP面向动词领域。

面向过程编程离我们已经有些遥远，面向对象编程正主宰着软件世界。当每个新的软件设计师都被要求掌握如何将需求功能转化成一个个类，并且定义它们的数据成员、行为，以及它们之间复杂的关系的时候，面向切面编程（Aspect-Oriented Programming，AOP）为我们带来了新的想法、新的思想、新的模式。

如果说面向对象编程是关注将需求功能划分为不同的并且相对独立，封装良好的类，并让它们有着属于自己的行为，依靠继承和多态等来定义彼此的关系的话；那么面向切面编程则是希望能够将通用需求功能从不相关的类当中分离出来，能够使得很多类共享一个行为，一旦发生变化，不必修改很多类，而只需要修改这个行为即可。

面向切面编程是一个令人兴奋不已的新模式。就开发软件系统而言，它的影响力必将会和有着数十年应用历史的面向对象编程一样巨大。面向切面编程和面向对象编程不但不是互相竞争的技术而且彼此还是很好的互补。

面向对象编程主要用于为同一对象层次的公用行为建模。它的弱点是将公共行为应用于多个无关对象模型之间。而这恰恰是面向切面编程适合的地方。有了 AOP，我们可以定义交叉的关系，并将这些关系应用于跨模块的、彼此不同的对象模型。AOP 同时还可以让我们层次化功能性而不是嵌入功能性，从而使得代码有更好的可读性和易于维护。它会和面向对象编程合作得很好。

参考资料：

百度百科-aop 百度百科-ioc

首先说下HibernateTemplate是spring的辅助类

事务的处理是使用了动态代理的设计模式，将事务处理作为一个独立的切面抽取出来，如果一个功能需要用到事务处理那么就在这个功能的基础上插入这个切面

以上就是关于spring-AOP(二) 自动代理全部的内容，包括:spring-AOP(二) 自动代理、Springboot 使用AOP实现防止接口重复提交、Spring AOP之AopProxy代理对象等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！