Spring源码相关学习笔记

Spring源码相关学习笔记

目录

• 流程图
• SpringBean的创建方式
• 谈谈Spring IOC的理解，原理与实现?
• 谈一下Spring IOC的底层实现?
• 描述一下bean的生命周期?
• Spring是如何解决循环依赖的问题的?
  • Spring缓存的放置时间和删除时间
• BeanFactory和FactoryBean的区别?
• Spring中运用到的设计模式？
• Spring中AOP的底层实现原理?
• Spring中事务是如何回滚的?
• 谈一下Spring中的事务传播?
• BeanFactory和ApplicationContext有什么区别？
• 在扫描生成BeanDefinition时，会排除接口和抽象类，再生成BeanDefinition
• spring的扩展点:
• DefaultListableBeanFactory 是最上层的实现，功能最全。

流程图

SpringBean的创建方式

• 声明式定义：
  • @Bean
  • @Component（@Service、@Controller）
• 编程式定义:
  • 直接通过BeanDefinition创建，比如：

    AnnotationConfigApplicationContext context = 
    new AnnotationConfigApplicationContext(AppConfig.class); 	
    // 生成一个BeanDefinition对象，并设置beanClass为User.class，并注册到ApplicationContext中 
    AbstractBeanDefinition beanDefinition = BeanDefinitionBuilder.genericBeanDefinition().getBeanDefinition();     
    beanDefinition.setBeanClass(User.class); 
    //注册到ApplicationContext中
    context.registerBeanDefinition("user", beanDefinition); 
    System.out.println(context.getBean("user"));
    

谈谈Spring IOC的理解，原理与实现?

总-分

• 总：

  • 控制反转：理论思想，原来的对象是由使用者来控制(new),有了spring之后，可以把整个对象交给spring来帮我们管理。
    • DI：依赖注入，把对应的属性的值注入到具体对象中，@Aurowired，populateBean 完成属性值得注入。
  • 容器： 存储对象，使用map结构来存储，在spring中一般存在三级缓存，singletonObjects存放完整的bean对象，整个bean的生命周期，从创建到使用到销毁的过程都是由容器来管理的（bean的生命周期）

• 分

  1. 一般聊ioc容器的时候要涉及到容器的创建过程:(BeanFactory，DefaultListableBeanFactory)，向bean工厂中设置一些参数(BeanPostProcessor,Aware接口的子类)等等属性。

  2. 加载解析bean对象，准备要创建的bean对象的定义对象BeanDefinition，(xml或注解的解析过程)。

  3. BeanFactoryPostProcessor的处理，此处是扩展点，PlaceHolderConfigurSupport，ConfigurationClassPostProcessor。

  4. BeanPostProcessor的注册功能，方便后续对bean对象完成具体的扩展功能。

  5. 通过反射的方式，将BeanDefinition对象实例化成具体的bean对象。

  6. bean对象的初始化过程(填充属性，调用aware子类方法，调用BeanPostProcessor前置处理方法，调用init-mothed方法，调用BeanPostProcessor后置处理方法)。

  7. 生成完整的bean对象，通过getBean()方法可直接获取。

  8. 销毁过程

面试官，这些是我对ioc的理解，包含了一些详细的处理过程，您看一下有什么问题，可以指点我一下(允许你把整个流程说完)

没看过源码怎么办？

具体细节记不太清了，但是spring中的bean都是通过反射的方式生成的，同时其中包含的很多扩展点，比如最常用的对BeanFactory的扩展，对bean的扩展(对占位符的处理)，我们公司对这方面使用的是比较多的，除此之外，ioc中最核心的也就是填充具体bean的属性，和bean的生命周期(背一下)

谈一下Spring IOC的底层实现?

反射，工厂，设计模式（会的说，不会的不说），关键的几个方法：
createBeanFactory,getBean,doGetBean,createBean,doCreateBean,
createBeanInstance(getDeclaredConstructor,newInstance),populateBean,initializingBean

1、先通过createBeanFactory创建出一个Bean工厂(DefaultListableBeanFactory)

2、开始循环创建对象，因为容器中的bean默认都是单例的，所以优先通过getBean，doGetBean从容器中查找。

3、找不到的话，通过createBean,doCreateBean方法，以反射的方式创建对象，一般情况下使用无参的构造方法(getDeclaredConstructor,newInstance)
* 如果多个构造方法，默认先用无参构造方法，如果多个且没有无参构造方法，则报错。
* 如果没有无参构造方法，且只有一个有参构造方法，则选用此有参构造方法。

4、进行对象的属性填充populateBean或@Autoward（依赖注入DI）

5、进行其他初始化操作(initializingBean)

描述一下bean的生命周期?

记住图中流程

1、实例化bean：反射的方式生成对象

2、填充bean的属性：populateBean(),循环依赖的问题(三级缓存)

3、调用aware接口相关的方法: invokeAwareMethod(完成BeanName,BeanFactory,BeanClassLoader对象的属性设置)

4、调用BeanPostProcessor中的前置处理方法：使用比较多的有(ApplicationContextPostProcessor，设置ApplicationContext，Environment，RsourceLoader，EmbeddValueResolver等对象)

5、调用init-mothed方法: invokeInitMethod(),判断了是否实现了initializingBean接口，如果有，调用afterPropertiesSet方法，没有则不调用

6、调用BeanPostProcessor的后置处理方法： spring的AOP就是在此实现的，AbstractAutoProxyCreator。
注册Destuction相关的回调接口

7、获取到完整的对象，可以通过getBean的方式来进行对象的获取

8、销毁流程：
①、判断是否实现了DispoableBean接口
②、调用destroyMethod方法

Spring是如何解决循环依赖的问题的?

三级缓存，提前暴露对象，aop

• 总：
  什么是循环依赖，A依赖B，B依赖A

• 分：
  先说明bean的创建过程：实例化，初始化(填充属性)

循环依赖出现的问题:
1. 先创建A对象，实例化A对象，此时A对象中的B属性为空，填充B属性
2. 从容器中查找B对象，如果找到了，直接赋值即不存在循环依赖问题(不通，B对象此时在容器中不存在)，找不到直接创建B对象
3. 实例化B对象，此时B对象中A属性为空，填充A属性
4. 从容器中查找A对象，找不到，直接创建A对象
如此，形成了闭环，形成闭环的原因：

此时，如果仔细琢磨，会发现第4步中，A对象其实是存在的(因为在第1步已经对A对象进行了实例化)，只不过是此刻A对象不是一个完整的状态，只完成了实例化而未完成初始化，如果在程序调试过程中，拥有了某个对象的引用，能否后期给他完成赋值操作。可以优先把非完整状态的对象优先赋值，等待后续操作来完成赋值，相当于提前暴露了某个不完整对象的引用。所以解决问题的核心在于实例化与初始化分开操作，这也就是解决循环依赖问题的关键。

当所有对象都完成实例化和初始化操作后，还要把完整对象放到容器中，此时容器中存在对象的两种状态： 完成实例化但未完成初始化(非完整状态)，完整状态。 因为都在容器中，所以要使用不同的map结构来存储，此时就有了一级缓存和二级缓存，如果一级缓存中有了，那么二级缓存中就不会存在同名对象，因为他们的查找顺序是1、2、3级缓存这样的方式。一级缓存中存放的是完整对象，二级缓存中存放的是非完整对象。

为什么需要三级缓存？ 三级缓存的value类型是ObjectFactory，是一个函数式接口，存在的意义是保证容器运行过程中，同名的bean对象只有一个。
函数式接口就是只定义一个抽象方法的接口

如果一个对象需要被代理，或者说需要生成代理对象，那么要不要优先生成一个普通对象？要

普通对象和代理对象是不能同时出现在容器中的，因此当一个对象需要被代理的时候，就要使用代理对象覆盖掉之前的普通对象，在实际调用的过程中，是没有办法确定对象什么时候被调用的，优先判断此对象是否需要被代理，类似于一种回调的机制，因此传入lambda表达式的时候，可以通过lambda表达式来执行对象的覆盖过程，getEarlyBeanReference()。

因此，所有的bean对象在创建的时候都要优先放入三级缓存中，在后续使用的过程中，如果需要被代理则返回代理对象，如果不需要被代理，则直接返回普通对象。

Spring缓存的放置时间和删除时间

三级缓存：createBeanInstance之后 ： addSingletonFactory()
二级缓存：第一次从三级缓存确定对象是代理对象还是普通对象的时候，同时删除三级缓存: getSingleton()
一级缓存: 生成完整对象之后放到一级缓存，删除二、三级缓存 : addSingleton()

BeanFactory和FactoryBean的区别?

相同点：都是用来创建bean的

不同的：使用BeanFactory创建对象的时候，必须遵循严格的生命周期流程，太复杂了，如果想要简单的自定义某个对象的时候，同时创建完成的对象想交给spring来管理，那么就需要实现FactoryBean接口了
* FactoryBean的三个方法
* isSingleton: 是否是单例对象
* getObjectType： 获取返回的对象类型
* getObject： 自定义创建对象的过程(new,反射,动态代理)

Spring中运用到的设计模式？

• 单例模式： bean默认都是单例的
• 原型模式： 指定作用域为prototype
• 工厂模式： BeanFactory
• 模板方法： postProcessorBeanFactory，onRefresh，initPropertyValue
• 策略模式： XmlBeanDefinitionReader，PropertiesBeanDefinitionReader
• 观察者模式： listener，event，multicast
• 适配器模式： Adapter
• 装饰者模式： BeanWrapper
• 责任链模式： 使用aop的时候会先生成一个拦截器链
• 委托者模式： delegate
  …

Spring中AOP的底层实现原理?

动态代理

aop是ioc的一个扩展功能，先有的ioc，再有的aop，aop只是在ioc整个流程中新增的一个扩展点而已： BeanPostProcessor

• 总：
  aop的概念：面向切面编程，通过预编译方式和运行其动态代理实现在不修改源代码的情况下给程序动态统一添加某种特定功能的一种技术。

应用场景：事务、日志…

动态代理

• 分：
  bean的创建过程中，有一个步骤可以对bean进行扩展实现，aop本身就是一个扩展功能，所以在BeanPostProcessor的后置处理方法中来进行实现。
  • 代理对象的创建过程(advice,切面,切点)
  • 通过jdk或者cglib的方式来生成代理对象
  • 在执行方法调用的时候，会调用到生成的字节码文件中，直接回找到DynamicAdvisoredinterceptor类中的intercept方法，从此方法开始执行。
  • 根据之前定义好的通知来生成拦截器链
  • 从拦截器链中依次获取每一个通知开始进行执行，在执行过程中，为了方便找到下一个通知是哪一个，会有一个CglibMethodInterceptor的对象，找的时候是从-1的位置依次开始查找并执行的

Spring中事务是如何回滚的?

Spring两种事务： 声明式事务、编程式事务

• 编程式事务使用TransactionTemplate或者直接使用底层的PlatformTransactionManager。对于编程式事务管理，spring推荐使用TransactionTemplate。(不常用)

• 声明式事务是建立在AOP之上的。其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。声明式事务最大的优点就是不需要通过编程的方式管理事务，这样就不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明(或通过基于@Transactional注解的方式)，便可以将事务规则应用到业务逻辑中。(常用)

spring的事务管理是如何实现的？

• 总：
  spring的事务是由aop来实现的，首先要生成具体的代理对象，然后按照aop的整套流程来执行具体的操作逻辑，正常情况下，要通过通知来完成核心功能，但是Spring中事务不是通过通知来实现的，而是通过一个TransationInterceptor来实现的，然后调用invoke来实现具体逻辑。

• 分：

  • 先做准备工作，解决各个方法上事务相关的属性(隔离性、传播性)，根据具体的属性来判断是否开启新事务
  • 当需要开启的时候，获取数据库连接，关闭自动提交功能，开启事务
  • 执行具体的sql逻辑操作
  • 在操作过程中，如果执行失败了，那么会通过complateTransationAfterThrowing来完成事务的回滚操作，回滚的具体逻辑是通过doRollBack()方法来实现的，实现的时候也是要先获取连接对象，通过连接对象来回滚。
  • 如果执行过程中，没有任何意外的发生，那么通过commitTransationAfterReturning来完成事务的提交操作，提交的具体逻辑是通过doCommit()来实现的，实现的时候也是要先获取连接对象，通过连接对象来提交。
  • 当事务执行完毕之后，需要清除相关的事务信息cleanupTransationInfo

如果想要更细致的话，需要知道TransationInfo，TransationStatus

谈一下Spring中的事务传播?

传播特性有几种? 7种
1. Required ：如果当前没有事务，就新建一个事务，如果已存在一个事务中，加入到这个事务中，这是最常见的选择。
2. Requires_new ： 新建事务，如果当前存在事务，把当前事务挂起。
3. Nested ： 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与Required类似的操作
4. Support： 支持当前事务，如果没有当前事务，就以非事务方法执行。
5. NotSupport： 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
6. Never： 以非事务方式执行操作，如果当前事务存在则抛出异常。
7. Mandatory： 使用当前事务，如果没有当前事务，就抛出异常。

某一个事务嵌套另一个事务怎么办？
如： A方法调用B方法，AB方法都有事务，并且传播特性不同。 那么A如果有异常，B怎么办？ B如果有异常，A怎么办？

• 总
  事务的传播特性指的是不同方法的嵌套调用的过程中，事务应该如何进行处理，是用同一个事务还是不同的事务？ 是当出现异常的时候会回滚还是提交？ 是两个方法之间的相关影响是什么？

在日常工作中用的比较多的是Required，Requires_new,nested

• 分

  1. 先说事务的不同分类，可以分为三类：支持当前事务、不支持当前事务、嵌套事务；
     支持当前事务：Mandatory->Required->Support (对事务依赖从强到弱)
     不支持当前事务：Never->Not Support->Requires_new (对事务依赖从强到弱)
     嵌套事务：Nested

  2. 如果外层方法是Required，内层方法是：Required、Requires_new、Nested

  3. 如果外层方法是Requires_new，内层方法是：Required、Requires_new、Nested

  4. 如果外层方法是Nested，内层方法是：Required、Requires_new、Nested

核心处理逻辑非常简单：
1、判断内外方法是否是同一个事务：
是：异常统一在外层方法处理
否：内层方法有可能影响到外层方法，但是外层方法是不会影响内层方法的
(大致可以这么理解，但是有个别情况不同->Nested)

面试中常问：
1、Required和Nested的区别：
在回答两种方式的区别的时候，最大的问题在于保存点的设置，很多人会认为内部设置Required和Nested的效果是一样的，其实在外层方法对内层方法的异常情况在进行捕捉的时候区别都不同。使用Required的时候，会报Transation roll back because it has been marked as rollback-only信息，因为内部异常了，设置了回滚标记，外部捕获之后，要进行事务提交，意味着要回滚，所以会报异常； 而Nested不会发生这种情况，因为在回滚的时候把回滚标记清除了，外部捕获异常后去提交，没发现回滚标记，就可以正常提交了。

2、Requies_new和Required的区别：
这两种方式产生的效果是一样的，但是Requies_new会有新的连接生成，而Nested使用的是当前事务的连接，而Nested还可以回滚到保存点，Requies_new每次都是一个新的事务回滚。但Nested其实是一个事务，外层事务可以控制内层事务的回滚，内层就算没有异常，外层出现异常，也可以全部回滚。

BeanFactory和ApplicationContext有什么区别？

BeanFactory是最底层接口，用于生产Bean。
ApplicationContext继承了BeanFactory。所以ApplicationContext也有生产Bean的能力，但是ApplicationContext主要的功能其中一个是将类读取成bean定义(BeanDefinition)。

在扫描生成BeanDefinition时，会排除接口和抽象类，再生成BeanDefinition

spring的扩展点:

• BeanFactoryPostProcessor接口(在容器启动阶段) Bean工厂的后置处理器 作用：修改beanDefinition
  BeanDefinitionRegistryPostProcessor接口是BeanFactoryPostProcessor接口的子类， Bean定义的后置处理器， 除了修改beanDefinition、还可以注册beanDefinition
• 各种Aware接口
• BeanPostProcessor接口
• InitializingBean接口(@PostConstruct,init-mothed)
• DisposableBean接口(@PreDestroy,destory-mothed)

DefaultListableBeanFactory 是最上层的实现，功能最全。

返回顶部