爱吃知识的土豆倪的博客

a. 因为 advisor 有多个, 且一个套一个调用, 因此需要一个调用链对象, 即 MethodInvocation。统一转换为环绕通知, 体现的是设计模式中的适配器模式（将一种接口转换成另一种接口，供调用 ）动态的通知调用有一处和静态的不一样有参数绑定的通知调用时还需要切点，对参数进行匹配及绑定。其余的和前面介绍的都一样，只是又额外添加了after 和 around的改写。前面都是介绍静态的通知调用，那么下面来说说动态通知调用。本质上就是通过递归的方式实现了责任链的调用。那么调用链是怎么实现的呢？

底层切点实现是如何匹配的: 调用了 aspectj 的匹配方法如果aspectj不能满足的话，那么就使用MethodMatcher 接口, 用来执行方法的匹配，通过这个我们完全可以自行的去定义匹配规则。代理的创建时间有两个一个是无循环依赖，那么就是 创建 -> 依赖注入 -> 初始化 这三个流程中的初始化之后创建代理。如果有循环依赖，那么就是 创建 -> 依赖注入 -> 初始化 这三个流程中 依赖注入之前创建代理，并且将其存入到二级缓存当中。

如果与jdk的方法反射做对比，jdk并不是一上来就优化，而是先调16次，第17次的时候，针对一个方法会产生一个代理类，代理类能让你的反射变成无需反射，原理和cglib差不多，而cglib是一上来就会产生代理，无需前16次准备工作。其实会将 反射优化成不反射调用了，直接通过类型 . 方法名正常调用了这个方法，并没有反射，但是代价就是因为将反射调用变成正常调用，会生成一个代理类（为了优化一个方法的反射调用，生成了一个代理类）那太枯燥了，而且大概率看不懂，所以还不如本着自己的思想来还原JDK的代理。

这是因为动态代理是基于接口或父类进行代理的，它是通过生成一个代理类来实现对目标类方法的代理。当目标类内部调用自己的方法时，实际上是在目标类的内部方法中直接调用，而不经过代理类。但是需要注意的一点就是 jdk 动态代理要求目标必须实现接口，生成的代理类实现相同接口，因此代理与目标之间是平级兄弟关系,所以哪怕将Target 改成final也没关系，因为不是子类（如果你需要在目标类的内部方法调用时也应用代理的增强逻辑，可以考虑将内部方法提取到一个独立的类中，并通过代理来调用该独立类的方法。

通过上图也可以看出，BeanFactory 与 ApplicationContext 并不仅仅是简单接口继承的关系, ApplicationContext 组合并扩展了 BeanFactory 的功能，如MessageSource 处理国际化资源的能力、ResourcePatternResolver 通配符匹配资源的能力（磁盘路径 类路径找到的文件）、ApplicationEventPublisher（发布事件对象）、EnvironmentCapable（读取Spring中的环境信息，环境变量）

Spring IOC 中的Bean生命周期大致分为四个阶段：实例化、属性赋值、初始化、销毁，如下图所示：其实核心的阶段就是这些了，但是每个核心的阶段里面又有很细致的划分。

对象来描述bean3成员变量的依赖，最后，会调用doResolveDependency（）方法来解析 bean3的依赖，这意味着Spring会尝试查找并注入名为“bean3”的成员变量所需的Bean，然后打印返回值，这主要是 “bean3”的依赖，也就是所需要的 Bean的实例。以上其实就将我们的beanFactory 配置好了，config里面的配置都被注册成了bean，用过Mybatis的都知道，最终我们使用的是Mapper接口，如果我们配置了Mapper接口，那么是否会被注册进来呢？

以上就是scope域的作用范围，但是细心的同学其实能发现，在Controller中，由于Spring的Bean默认是单例的，而我们@Autowired都不是单例，甚至随着作用域的变化而变化，都分别加了@Lazy 注解，那么这个注解的作用是什么呢？不同于我们前面章节所介绍的后置处理，我们不需要添加任何的后置处理器，只需要实现对应的Aware接口，在运行的时候，就会执行对应的实现方法了。对于单例对象来讲，依赖注入仅发生了一次，后续再没有用到多例的 F，因此 E 用的始终是第一次依赖注入的 F。