Java框架学习（三）spring5高级49讲

1、BeanFactory与ApplicationContext

BeanFactory负责：

• 创建、管理和配置应用程序中的对象（Bean）
• 实现IoC（控制反转）和DI（依赖注入）
• 是spring的核心机制。

ApplicationContext是BeanFactory的子接口。与BeanFactory相比，ApplicationContext组合了另外四个接口功能，使其可以支持：

• 国际化（MessageSource，多语言支持）
• 资源解析加载（ResourcePatternResolver，根据通配符匹配资源名加载资源）
• 获取环境配置信息（EnvironmentCapable，根据配置的环境参数加载不同的配置文件，从而实现在不同环境下的灵活配置和适配。）
• 事件发布功能（ApplicationEventPublisher，允许应用程序中的Bean发送事件。同时，其他Bean可以监听这些事件，使用@EventListener注解，并在事件发生时采取相应的处理措施。这为应用程序的解耦和模块间通信提供了便利的机制）。

2、BeanFactory与ApplicationContext的容器实现

BeanFactory的容器实现

1、创建BeanFactory的实现类对象。
2、定义bean（类型、scope等），并注册到BeanFactory
3、注册常用的后处理器。（解析注解，注入等）

BeanFactory不会做的事：

• 不会主动添加Bean后处理器
• 不会主动调用Bean的后处理器来解析注解
• 不会主动初始化单例
• 不会解析 $ 与#

可以看出BeanFactory实现的是容器的基本功能，而下边要讲的ApplicationContext的容器实现，则会将上边的功能一一实现。

后处理器排序

Bean的后处理器有很多，用来解析不同的注解，比如@Autowired、@Resource等，处理器有其固定的执行的顺序，当然也可通过添加比较器的方式来改变。

@Autowired与@Resource同时出现时，执行结果与Bean后处理器执行顺序有关。

ApplicationContext的容器实现

Spring中的ApplicationContext是用于管理Bean的高级容器，提供了多种实现方式来适应不同场景和需求。其中常见的四种实现方式分别是：

1、ClassPathXmlApplicationContext：通过类路径下的XML配置文件加载和管理Bean。

2、FileSystemXmlApplicationContext：通过文件系统路径加载XML配置文件来管理Bean。

3、AnnotationConfigApplicationContext：基于Java注解的实现方式，使用@Configuration和@Bean注解配置Bean。

4、WebApplicationContext：用于Web应用，加载Web相关的配置信息。

1、2都是基于XML文件配置来构建容器内容，1是通过加载XML文件资源读取，2是直接XML文件路径读取。

3、4都是基于@Configuration和@Bean注解配置，不同的是第4种方式集成了TomcatServer，配置了与网页请求处理相关的Bean，主要包括：ServletWebServerFactory、Servlet分发、Servlet请求分发注册，以及相应请求路径的控制器Bean。

3、Bean的生命周期

Bean主要是生命周期包括：

• 1、实例化。
• 2、依赖注入：@Autowired
• 3、初始化：@PostConstruct
• 4、销毁：@PreDestroy

Bean后处理器

除了基本的4个生命周期，还可以通过添加Bean后处理器，定位到更加精细的生命周期阶段，以便进行功能的增强，比如：

• 实例化执行之前、实例化执行之后
• 依赖注入之前（@Autowired、@Resource、@Value）
• 初始化之前、初始化之后
• 销毁执行之前

4、常见的Bean后处理器

• 1、common注解后处理器：解析 @Resourse、@PostConstruct、@PreDestroy
• 2、autowired注解处理器：解析@Autowired、@Value

从上边结果看到，common后处理器的执行优先级更高。

• ConfigurationPropertiesBindingPostProcessor：解析@ConfigurationProperties

5、常见BeanFactory后处理器

• ConfigurationClassPostProcessor：主要职责就是解析@Configuration注解的类，识别其中的@Bean方法，还可以解析@ComponentScan、@Import、@ImportResource
• MapperScannerConfigurer：解析@Mapper，对应mybatis的MapperScan注解。

6、Aware和InitializingBean接口

Aware接口是一组特殊的接口，它们允许Bean感知或获取容器的某些方面或上下文信息。通过实现Aware接口，Bean可以与Spring容器进行交互，并获取一些有用的信息或执行特定的操作。

使用InitializingBean接口可以实现Bean的初始化逻辑。

Aware和InitializingBean接口实现的功能，使用Bean后处理器也可以实现，但Aware和InitializingBean是内置接口功能，不依赖外部，是一种内聚的使用方法，而后处理的方法是分模块解耦的，如果其他模块失效，则后处理器的执行也可能失效。

7、初始化与销毁阶段的回调

指定初始化的方法有3种：

• 1、通过后处理器的@PostConstruct
• 2、通过 InitializingBean内置的接口
• 3、通过在@Bean注解时，指定参数
  
  

执行的优先级：

销毁的方式与初始化类似也有3种：

8、Bean的作用域scope

Spring提供了以下几种常见的Bean作用域：

• Singleton（单例）：在整个应用程序的生命周期内，只创建一个Bean实例。每次请求该Bean时，都返回同一个实例。这是Spring的默认作用域。
• Prototype（原型）：每次请求该Bean时，都会创建一个新的Bean实例。即每次获取Bean，都返回一个全新的实例。
• Request（请求）：每个HTTP请求都会创建一个新的Bean实例，适用于Web应用程序。
• Session（会话）：每个用户会话（Session）创建一个新的Bean实例，适用于Web应用程序。
• Application（应用）：在整个Web应用程序的生命周期内，只创建一个Bean实例，适用于Web应用程序。
• WebSocket（Web Socket）：在WebSocket会话的生命周期内，每次创建一个新的Bean实例。

scope失效

1、一个作用域为单例的bean，如果要注入其他作用域（非单例）的bean对象，那么这个非单例作用域会失效。

实验：在单例的e中，有成员f，注入，而f是一个多例的作用域。最后的结果是e中获取到的f不是多例，而是同一个。

原因在于：
对于单例对象而言，依赖注入仅发生了一次，后续没有再用的多例的F，因此E用的始终是第一次依赖注入的F。

解决方法1：使用@Lazy注解，添加在要注入的对象上，该注解仅在使用对象时，才会通过f的代理的方法，创建出f，这样调用的f就是多例的。

解决方法2：可以通过在多例对象的scope注解中，指定参数，设置代理模式。

解决方法3：注入F的工厂，获取方法中，使用工厂构建，然后返回

解决方法4：注入容器对象，获取方法中，使用容器构建出对象。

9、基于AJC编译器实现AOP

AJC（AspectJ Compiler）是AspectJ编译器的缩写。AspectJ是一种Java语言的扩展，它是AOP（面向切面编程）的一个实现。AspectJ允许开发者在Java代码中直接定义切面（Aspects），从而实现横切关注点的功能，例如日志记录、性能监控、事务管理等。

AJC的实现需要在Maven中引入AJC编译器插件

AJC编译器会直接将@Aspect增加的内容，写入到目标类中。

待增强的类：

aspect：

在编译后，生成的target中，可以看到我们的目录类已经被改写，增强的切面内容已经写入了目标类中：

基于AJC编译器实现的AOP，不同于spring容器中，基于代理的实现。因此AJC增强，不需要借助spring容器，而且它可以增强静态方法，而基于代理实现的增强，它的本质是通过重写方法，而静态方法是不可被重写的。

10、基于agent类加载实现AOP

基于agent类加载实现AOP指的是在在运行时，通过指定系统运行参数，基于agent类加载来实现增强。

实验：
切面指向待增强类中所有的方法：

运行时虚拟机参数设置：

bashjavaagent:C:\Users\123\.m2\repository/org/aspectj/aspectjweaver/1.9.4/aspectjweaver-1.9.4.jar

AJC在编译阶段实现了AOP增强，因此可以在target中找到编译对象，通过反编译查看增强后的目标类。

基于agent类加载实现的增强，增强的目标运行在JVM中。
可以通过阿里的Arthas工具，调试正在运行的程序：

通过 jad命令，指定待增强的目标类：

然后就可以看到类加载增强的内容。

11、基于JDK动态代理 / CGLIB动态代理 实现AOP

JDK动态代理：对于实现了接口的目标对象，Spring使用JDK动态代理来创建代理对象。JDK动态代理是通过Java原生的java.lang.reflect.Proxy类来实现的。代理对象实现了目标接口，并在InvocationHandler的invoke方法中添加了增强逻辑，即基于反射，method.invoke('待增强对象', '方法参数')；

JDK动态代理只能针对接口代理！

注意：代理对象没有源码，是在运行期间动态生成的字节码，因此代理对象需要传递加载器，将字节码加载对代理对象。

CGLIB动态代理：对于没有实现接口的目标对象，Spring使用CGLIB动态代理来创建代理对象。CGLIB（Code Generation Library）是一个代码生成库，它通过生成目标类的子类来实现代理。代理对象继承了目标类，并在其子类中添加了增强逻辑。

核心逻辑是基于Code Generation Library中的
Enhancer.create()方法，生成代理类为待增强目标的类的子类。

所以cglib动态代理只能针对可继承的待增强对象进行代理！

cglib动态代理对于方法的调用有三种：
1、通过方法反射的方式，method.invoke(target，args)
2、通过方法代理对象，传入目标对象调用，非反射，需要目标
3、通过方法代理对象，传入代理对象调用，非反射，需要代理。这里传入的代理是FastClassProxy

12、JDK动态代理实现原理

JDK动态代理是基于反射实现的。

• 1、代理对象必须实现InvocationHandler接口，JDK在实现时是继承了Proxy类，提供了InvocationHandler的构建方法，在执行时通过super，传入InvocationHandler。
• 2、使用Proxy.newProxyInstance产生代理对象，代理对象是基于ASM（字节码操作框架）技术，动态生成的字节码，因此需要传入类加载器，将字节码加载为对象。
• 3、接口方法的获取是通过反射的方式，即从类的字节码中调用getMethod方法得到的，为了避免多次调用的getMethod的开销，代理对象内部使用静态成员保存了方法，并通过静态代码块进行了初始化赋值。
• 4、为了处理有返回值的方法，代理对象中的返回值为Object对象。方法中对于异常的捕获和处理，分为了运行时异常和受检时异常，对于运行时异常直接抛出，对于受检异常，将其包装为UndeclaredThrowableException后，再抛出。
• 5、jdk反射优化，接口方法增强时，采用了反射的方式调用方法，这样性能是有损耗的，jdk内部对此进行了优化，当调用次数到第17次时，jdk内部会生成一个有该方法的代理对象，直接调用该代理对象的方法，而不再使用反射的形式调用。

13、CGLib动态代理实现原理

JDK动态代理增强的是实现了接口的目标类，本质上基于反射。
CGLib动态代理采用继承 + 方法拦截器的方式，针对可继承的目标类进行增强。

1、生成代理类：当目标类需要被代理时，CGLIB会在运行时生成一个代理类，该代理类继承自目标类，成为目标类的子类。

2、拦截器：在CGLIB中，代理的逻辑由一个拦截器（MethodInterceptor）来实现，拦截器负责在代理类的方法调用前后执行额外的逻辑。拦截器类似于JDK动态代理中的InvocationHandler。

3、方法调用的重定向：在代理类的方法调用时，CGLIB会将方法的调用重定向到拦截器的intercept()方法中。在intercept()方法中，可以实现对目标方法的增强逻辑，并调用目标方法。

4、代理对象创建：通过字节码生成技术，CGLIB将代理类的定义转换为字节码，并使用ClassLoader加载字节码，最终生成代理对象。

14、MethodProxy

cglib中基于MethodProxy的目标方法调用，是直接调用而非反射，这使得它的性能会优于JDK动态代理的方式。

在CGLIB源码中，MethodProxy类的主要实现是由FastClass类和MethodInfo类配合完成的。下面简要解释MethodProxy的实现原理：

1、FastClass：FastClass是CGLIB中的一个关键类，它负责快速调用一个类的方法，而无需像反射那样通过Method对象进行调用。FastClass通过方法的索引号直接进行方法调用，从而提高了调用的效率。FastClass通过ASM库在运行时生成一个快速调用方法的类。

2、MethodInfo：MethodInfo用于表示目标类中的一个方法。它包含了方法的名称、访问修饰符、返回类型、参数类型等信息。

3、MethodProxy：在生成代理类的过程中，CGLIB会为每个目标方法生成一个对应的MethodProxy对象。MethodProxy中包含了目标方法的索引号和方法签名等信息。

4、在代理类的方法调用时，代理对象会通过MethodProxy的invoke(Object obj, Object[] args)方法来调用目标方法。invoke()方法内部会通过FastClass来快速调用目标方法，而无需使用Java反射。通过FastClass的invoke(int methodIndex, Object obj, Object[] args)方法，根据目标方法的索引号直接调用目标方法。

通过这种方式，CGLIB避免了Java反射带来的性能开销，实现了高性能的动态代理。MethodProxy是实现这一机制的重要组成部分，它使得CGLIB动态代理在对没有实现接口的类进行代理时，具有了更高的效率和性能。

CGLIB和JDK动态代理的实现区别

CGLIB和JDK动态代理是两种不同的动态代理实现方式，它们在原理、适用场景和性能方面有一些区别。下面讲解一下它们的区别：

• 原理和实现方式：

  • JDK动态代理：JDK动态代理是通过Java原生的java.lang.reflect.Proxy类和InvocationHandler接口来实现的。在运行时，JDK动态代理通过生成目标接口的代理对象，并通过InvocationHandler的invoke()方法来实现对目标方法的拦截和增强。
  • CGLIB动态代理：CGLIB动态代理是通过CGLIB库，利用字节码生成技术，在运行时生成目标类的子类作为代理类。在子类中，CGLIB通过生成MethodProxy对象实现对目标方法的拦截和增强。

• 代理类型：

  • JDK动态代理：JDK动态代理只能代理实现了接口的目标类。如果目标类没有实现任何接口，就无法使用JDK动态代理进行代理。
  • CGLIB动态代理：CGLIB动态代理可以代理没有实现接口的目标类。它通过生成目标类的子类来实现代理，因此对于没有接口的类也能够代理。

• 性能：

  • JDK动态代理：JDK动态代理在调用代理方法时，涉及到反射调用，有一定的性能开销。代理效率相对较低，尤其在代理方法较多时性能下降较明显。
  • CGLIB动态代理：CGLIB动态代理在调用代理方法时，通过直接调用生成的子类的方法，无需反射调用，因此相对于JDK动态代理，性能更高。特别适用于代理方法较多或代理对象创建较频繁的情况。

• 依赖和兼容性：

  • JDK动态代理：JDK动态代理依赖于Java原生的java.lang.reflect.Proxy类，对于Java平台的兼容性较好，无需额外引入第三方库。
  • CGLIB动态代理：CGLIB动态代理依赖于CGLIB库，使用时需要引入相应的依赖。CGLIB动态代理在Java平台上运行良好，但在其他Java虚拟机（JVM）上可能存在兼容性问题。

15、Spring AOP与选择代理

AOP（Aspect Oriented Programming，面向切面编程），其实就是面向特定方法编程，可以是对原来方法的增强，也可以是对原有方法的改编。

例如需要统计某个方法的执行时长分析：

AOP核心概念

• 连接点：JoinPoint，可以被AOP控制的方法（暗含方法执行时的相关信息）
• 通知：Advice，指哪些重复的逻辑，也就是共性功能（最终体现为一个方法）
• 切入点表达式：PointCut，匹配连接点的条件，通知仅会在切入点方法执行时被应用。通常使用切入点表达式，来匹配切入的方法。
• 切面：Aspect，描述通知与切入点的对应关系（通知 + 切入点）
• 单通知切面：Advisor，一种粒度更细的切面，只包含一个通知和切点的切面。
• 目标对象：Target，通知所应用的对象。

通知（Advice）类型

• 前置通知（Before Advice）：在目标方法执行之前执行的通知。用于在目标方法执行前做一些预处理操作。

• 后置通知（After Advice）：在目标方法执行之后执行的通知。无论目标方法是否成功执行，后置通知都会执行。

• 返回通知（After Returning Advice）：在目标方法成功执行并返回结果后执行的通知。可以访问目标方法的返回值。

• 异常通知（After Throwing Advice）：在目标方法抛出异常后执行的通知。用于处理异常情况。

• 环绕通知（Around Advice）：在目标方法执行前后都可以执行的通知。它可以完全控制目标方法的执行，包括是否执行目标方法和在何处执行目标方法等。

注： @Around 环绕通知与其他类型通知有所不同：

• @Around 环绕通知需要自己调用 ProceedingJoinPoint.proceed()来让原始方法执行，如果原始方法有返回值，需赋值给Object对象，而其他通知类型则不需要处理原始方法。
• @Around 环绕通知的连接点类型为ProceedingJoinPoint，而其他通知的连接点类型为JoinPoint，是ProceedingJoinPoint的父类。

@Order控制通知顺序

当有多个切面的切入点都匹配到了目标方法，多个通知都会执行。那么执行顺序是怎样的呢?

• 1、不同切面类中，默认按照切面类类名字母排序
  • 目标方法前的通知：字母排序靠前先执行
  • 目标方法后的通知：字母排序靠后先执行
• 2、可以通@order（数字）注解加在切面类上，执行优先级
  • 目标方法前的通知：数字小的先执行
  • 目标方法后的通知：数字大的先执行

顺序控制只能以切面类为单位，类中的具体的通知方法，无法控制顺序。

切入点表达式（Pointcut）与@PointCut

使用切入点表达式，来匹配到切入的方法，匹配的方式有：

• execution(……)：根据方法的返回值、包名、类名、方法名、方法参数等信息匹配，使用execution
• @annotation(……)：根据注解匹配
  

切入点表达式可以通过注解@Pointcut抽取出来。然后在需要的地方复用：

连接点（JoinPoint）

连接点是增强方法的入参，用于获取实际运行方法的信息。

基于代码实现的AOP

需要四个步骤：

• 1、备好切点
• 2、备好通知
• 3、备好切面（切点 + 通知）
• 4、创建代理

Spring对于代理的选择规则

Spring 框架会自动根据目标 bean 的特性选择合适的代理方式。这个选择是透明的，开发者无需显式指定使用哪种代理方式。当配置了 Spring AOP 时，如果目标 bean 实现了接口，Spring 将使用 JDK 动态代理；如果目标 bean 没有实现接口，Spring 将使用 CGLIB 代理。

对于上边实验中，使用ProxyFactory创建的代理对象：

• 如果设置了proxyTargetClass = false，且目标实现了接口，那么用jdk实现。
• 如果设置了proxyTargetClass = false，目标没有实现接口，则使用cglib实现。
• 如果设置了proxyTargetClass = true，总是使用cglib实现。

16、切入点匹配

使用切入点表达式，来匹配到切入的方法，匹配的方式有：

• execution(……)：根据方法的返回值、包名、类名、方法名、方法参数等信息匹配，使用execution
• @annotation(……)：根据注解匹配

17、从@Aspect到@Advisor

Aspect是一种高级切面，实现起来较为简单，可以通过注释：

Advisor则是一种低级的切面，常在框架实现内部中使用。创建Adivisor需要切点 + 通知（由MethodInterceptor创建）

Spring启动过程中，会解析所有的切面，如果是高级切面Aspect会转为低级切面Adviser。

18、通知的执行

基于适配器模式将所有通知转为环绕通知

无论ProxyFactory基于哪种方式（JDK或者CGLib）创建代理，最后调用Advice通知的都是一个MethodInvocation对象，非环绕通知会统一转为环绕通知再执行。

基于责任链模式实现通知的执行

19、动态通知调用

• 静态通知调用：不带参数绑定
• 动态通知调用：需要参数绑定

41、Spring自动配置原理

@Import三方配置引入

有的时候我们需要为三方依赖做一些配置类bean，为了方便其他项目复用，通常会将其写在一个配置类中，本项目在使用该配置类时，可以通过@Import注解，将其导入到本项目的配置类：

上边的写法，如果三方配置类太多，@Import注解参数会很多，可以构建一个ImportSelect，把三方配置类信息的，放入ImportSelect类中：

进一步的，避免在Java代码中列举配置类信息，可以直接在配置文件中列举出配置信息，然后导入，这个配置文件，一般约定写在resource目录下的META_INF目录中的.factories文件中：

然后在ImportSelector中，只需要使用SpringFactoriesLoader加载，并转为string类型的列表即可：

Bean同名冲突：
如果配置时，三方依赖的配置的bean和本项目中配置的bean有相同的，后边配置的Bean会覆盖前边配置的。

如果不想被覆盖可以将setAllowBeanDefinitionOverriding设置为false：

那么怎么保证配置的导入顺序呢？
可以将ImportSelector接口，更改为DeferredImportSelector接口，即延迟三方的配置，优先保证本项目的配置先执行：

然后在三方配置类中：
使用@ConditionOnMissingBean注解，仅在缺少该Bean的时候才使用：

SpringBoot启动时的自动配置原理

Spring启动时，有一个注解@SpringBootApplication，它可以看作是三个注解的集合：

• @Configuration ：允许在上下⽂中注册额外的 bean 或导⼊其他配置类
• @ComponentScan ： 扫描被 @Component ( @Service , @Controller
  )注解的 bean，注解默认会扫描该类所在的包下所有的类。
• EnableAutoConfiguration ：启⽤ SpringBoot 的⾃动配置机制，该注解是由：
• • @AutoConfigurationPackage：用于指定自动配置类的扫描范围的注解，它通常被放置在启动类上，用于设置自动配置的基础包路径。
  • @ Import注解 ，作用是导入配置类或者Bean到当前类中，EnableAutoConfiguration中 的Import注解会导入自动配置导入选择器，AutoConfigurationImportSelector，而这个导入选择器会将Resource中的META-INF / spring.factories里边配置的所有自动配置Bean加入到Spring容器中。

总结：

• 1、Spring启动类会加@SpringBootApplication注解，该注解可以看作是三个主要的注解@Configuration，@ComponentScan和@EnableAutoConfiguration的集合。
• 2、@Configuration声明了启动类为主配置类，@ComponentScan则会扫描主配置类及其所在包下所有类，将@Component注解标识的类或@Component的复合注解，如@Service、@Controller、@Repository等加入到Spring容器。
• 3、重点是@EnableAutoConfiguration注解，它可以看作是@AutoConfigurationPackage和@Import注解的集合，@AutoConfigurationPackage 作用是告诉Spring Boot 自动配置类的扫描范围，默认会限定在主类所在的包及其子包中搜索自动配置类。@Import注解中导入的AutoConfigurationImportSelector则会调用SpringFactoryLoader将META-INF目录下spring.factory文件中声明的Bean都加入到Spring容器中。

自定义自动配置导入Spring

47、@Autowired底层

@Autowired是按类型来注入的，底层实现比较复杂。

48、事件监听器

事件发布与处理流程

第一步：构建事件对象，继承自ApplicationEvent
第二步：通过时间发布器，发送事件：

第三步：事件监听者实现监听器接口，即ApplicationListener，该接口需要提供事件类型，作为泛型的实例化。然后重写接口的onApplicationEvent()方法，实现事件处理逻辑。

事件监听者也可以通知@EventListener注解的方式，直接加载监听者处理监听事件的方法上边，来实现监听，注意，就像接口中需要传递事件类型一样，监听处理方法需要传入事件对象：

采用线程池来异步处理事件

publisher事件发布在底层是调用了一个SimpleApplicationEventMuticaster，来广播通知事件的。默认没有使用线程池，但我们可以通过设置线程池对象taskExecutor，让事件的执行变为异步处理。


通过@Bean注解，构建线程池对象，Spring容器将在我们需要这个对象的时候，执行该方法返回给我们线程池对象。

自定义注解模拟@EventListener实现原理

49、自定义事件分发器模拟事件发布

第一步：创建抽象方法实现应用事件发布器接口 ApplicationEventMulticaster
第二步：构建事件发布器@Bean方法，返回事件发布器对象，先从容器中获取到监听器集合，然后需要重写事件发布器的 两个方法：addApplicationListener()用于收集监听器，multicastEvent()，用于事件发布。

第三步：在收集监听器方法中，需要获取到监听器的事件类型，然后将监听器包装为支持事件类型检查的监听器GenericApplicationListener，仅在事件类型与监听类型一致时，才执行事件发布，这里也可将其发布到线程池中。最后将支持类型检查的监听器加入到监听器集合。
第四步：由于监听器集合中是已经封装为有事件类型检验功能的监听器，可以调用它的事件类型检验支持功能 supportEventType()来决定是否执行监听器的事件发布回调。