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与选择代理