weixin_48254383的博客

发布前先通过 GenericApplicationListener.supportsEventType 判断支持该事件类型才发事件。监听器会统一转换为 GenericApplicationListener 对象，以支持判断事件类型。addApplicationListenerBean 负责收集容器中的监听器。转化为ApplicationListener接口的实现。实现 ApplicationListener 接口。可以利用线程池进行异步发事件优化。根据监听器方法参数确定事件类型。根据接口泛型确定事件类型。

在bean的初始化之前，有属性填充的步骤在AutowiredAnnotationBeanPostProcessor的**postProcessProperties()**方法中，会遍历所找到的注入点依次进行注入，注入点即为标注了@autowird、@vaule及@inject注解的属性或者set方法，因此在进行注入操作会分有两种方式，分别为字段注入和set方法注入，对应。查看需要的类型是否为 ObjectFactory 或 ObjectProvider，是，则进行封装（延迟），否则向下走。

它的作用是用制造创建过程较为复杂的产品, 如 SqlSessionFactory, 但 @Bean 已具备等价功能。会认为创建、依赖注入、Aware 接口回调、前初始化这些都是 FactoryBean 的职责, 这些流程都不会走。按名字去获取时, 拿到的是产品对象, 名字前面加 & 获取的是工厂对象。在spring中，前此接口的实现仍被大量使用, 想被全面废弃很难。唯有后初始化的流程会走, 也就是产品可以被代理增强。被 FactoryBean 创建的产品。

自动配置类本质上就是一个配置类而已，只是用 META-INF/spring.factories 管理，与应用配置类解耦@Enable 打头的注解本质是利用了 @Import@Import 配合 DeferredImportSelector 即可实现导入，selectImports 方法的返回值即为要导入的配置类名DeferredImportSelector 的导入会在最后执行，为的是让其它配置优先解析));//spring识别的import。

这其中有异常，发布 application failed 事件7️⃣。这其中有异常，发布 application failed 事件7️⃣。发布 application context 已初始化事件3️⃣。发布 application context 已初始化事件3️⃣。发布 application starting 事件1️⃣。发布 application starting 事件1️⃣。发布 application started 事件5️⃣。发布 application started 事件5️⃣。

通知共有五种类型，最终都是转换为环绕通知执行，其他几种通知就需要转换为环绕通知，因此就需要适配其他几种通知，转化为中间的类或者对象即为是适配器对象。进入环绕通知2，执行前增强，调用 mi.proceed() 发现没有环绕通知，调用 mi.invokeJoinPoint() 执行目标方法。进入环绕通知1，执行前增强，再次调用 mi.proceed() 发现有下一个环绕通知，调用它的 invoke(mi)环绕通知2继续将结果返回给环绕通知1，执行环绕通知1 的后增强。多个通知通过调用链执行，内部为递归调用。

bean2依赖bean1的时候，并且bean1也依赖于bean2，即为循环依赖，bean1中有需要增强的方法，代理对象则是在bean1初始化之后创建，bea2则注入bea1的代理对象。bean2依赖注入bean1，由于bean1中的方法需要增强，因此需要注入代理对象，在bean实例化后，创建bean1的代理对象。有【资格】的 Advisor 一部分是低级的, 可以由自己编写, 如本例 A17 中的 advisor3。根据不同通知类型注解实现对应底层通知的实现，最终都是转化为环绕通知类型。

切面：Advisor，包含一个 Advice 通知，PointcutAdvisor 包含一个 Advice 通知和一个 Pointcut。如果指定了接口，且 proxyTargetClass = false，使用 JdkDynamicAopProxy。b. proxyTargetClass = false, 目标没有实现接口, 用 cglib 实现。a. proxyTargetClass = false, 目标实现了接口, 用 jdk 实现。Spring 中对切点、通知、切面的抽象如下。

和 jdk 动态代理原理查不多回调的接口换了一下，InvocationHandler 改成了 MethodInterceptor调用目标时有所改进，见下面代码片段method.invoke 是反射调用，必须调用到足够次数才会进行优化methodProxy.invoke 是不反射调用，它会正常（间接）调用目标对象的方法（Spring 采用）methodProxy.invokeSuper 也是不反射调用，它会正常（间接）调用代理对象的方法，可以省略目标对象。

jdk代理实现原理方法重写可以增强逻辑，只不过这【增强逻辑】千变万化，不能写死在代理内部通过接口回调将【增强逻辑】置于代理类之外配合接口方法反射（是多态调用），就可以再联动调用目标方法会用 arthas 的 jad 工具反编译代理类限制⛔：代理增强是借助多态来实现，因此成员变量、静态方法、final 方法均不能通过代理实现。

jdk 动态代理要求目标必须实现接口，生成的代理类实现相同接口，因此代理与目标之间是平级兄弟关系newProxyInstance参数分别为类加载器，代理类需要实现的接口，具体的目标方法及增强逻辑目标类可以使用final修饰void foo();// jdk 只能针对接口代理// 目标对象//类加载器，因为使用反射需要将字节码加载到jvm中});foo.foo();

运行时需要在 VM options 里加入 -javaagent:C:/Users/manyh/.m2/repository/org/aspectj/aspectjweaver/1.9.7/aspectjweaver-1.9.7.jar 把其中 C:/Users/manyh/.m2/repository 改为你自己 maven 仓库起始地址。使用非代理的形式实现AOP即使用了ajc的编辑器，改写了目标对象的class文件，和spring没有联系。实现的话需要增加ajc编译插件的pom依赖。

在当前版本的 Spring 和 Spring Boot 程序中，支持五种 Scopesingleton，容器启动时创建（未设置延迟），容器关闭时销毁prototype，每次使用时创建，不会自动销毁，需要调用 DefaultListableBeanFactory.destroyBean(bean) 销毁request，每次请求用到此 bean 时创建，请求结束时销毁session，每个会话用到此 bean 时创建，会话结束时销毁。

Java 配置类包含 BeanFactoryPostProcessor 的情况，因此要创建其中的 BeanFactoryPostProcessor 必须提前创建 Java 配置类，而此时的 BeanPostProcessor 还未准备好，导致 @Autowired 等注解失效。就如myconfig1类，需要先将Myconfig1解析创建，然后解析@Bean新增的bean工厂后置处理器，在创建的时候由于BeanPostProcessor 还未执行，因此Autowired也不执行，此时类已经创建完成。

获取componentScan注解的basepage属性值，即为包名，并将其转为路径获取类路径下的所有资源类文件，获取其元数据根据其元数据判断类中是否有component注解及其派生注解有的话注册bd到map中获取该类的元数据获取类中所有标注@bean注解的方法根据方法构造bd，注册到Map中单个mapper可以使用@bean注入多个mapper使用mapperscan获取mapperscan的包转为类路径，并获取资源获取资源的下类的元信息。

AutowiredAnnotationBeanPostProcessor.findAutowiringMetadata 用来获取某个 bean 上加了 @Value @Autowired 的成员变量，方法参数的信息，表示为 InjectionMetadata。@Autowired 等注解的解析属于 bean 生命周期阶段（依赖注入, 初始化）的扩展功能，这些扩展功能由 bean 后处理器来完成。InjectionMetadata 可以完成依赖注入。每个后处理器各自增强什么功能。

在容器的启动的时候，bean的加载等过程都是固定的，如bean后置处理器的加载，autowird注入已经实现，如果需要增加resource注入，就需要改变bean后置处理器加载的代码，此时需要对bean进行增强扩展，可能就要改动原流程的逻辑，但是使用模板方法设计，抽象出来一个接口，去实现不同的增强，相当于说给外界留下一个增强点，可以增加自定义的增强逻辑，如果要增加新resource注入功能，则在后在后置处理器接口。这里返回的对象会替换掉原本的 bean。这里返回的对象会替换掉原本的 bean。

另外要注意的是，后面这些带有 ApplicationContext 的类都是 ApplicationContext 接口的实现，但它们是。AnnotationConfigWebApplicationContext，传统 SSM 整合时，基于 java 配置类的容器（旧）ClassPathXmlApplicationContext，从类路径查找 XML 配置文件，创建容器（旧）XmlWebApplicationContext，传统 SSM 整合时，基于 XML 配置文件的容器（旧）

本合集是学习课程【黑马程序员Spring视频教程，深度讲解spring5底层原理-哔哩哔哩】的笔记，主要为课程笔记、练习代码及自己的一些理解，目前计划在两个月内完成学习，暂不涉及web章节。