Spring

控制反转

• 对象创建不再通过主动创建，而是交给第三方 spring 容器进行管理
• DI:依赖注入 ，组件间的依赖关系由spring 容器进行决定，当某一个对象需要使用另一个对象时，以前是由使用者主动创建对象，现在是直接用 spring 容器去要这个对象

容器

• 存储对象，使用  map 结构进行存储，在spring中一般存在三级缓存，singletonObject 存放完整的 bean 对象
• 整个 bean的生命周期从创建、使用、销毁全由容器进行管理

Bean 生命周期

四个阶段（doCreate()）

• 实例化 Instantiation（createBeanInstance()）
• 属性赋值 Populate（populateBean() ）
• 初始化 Initialization（initializeBean()）
• 销毁 Destruction （容器关闭时调用的 ConfigurableApplicationContext#close()）

Bean  周期具体流程

• 实例化 Bean：反射的方式生成对象

• 填充 Bean 属性：populateBean() ，循环依赖的问题（三级缓存）

• 调用 aware 接口相关方法：invokeAwareMethod（完成BeanName、BeanFactory、BeanClassLoader 对象的属性赋值）

• 调用 BeanPostProcesser 中的前置方法设置ApplicationContext、Environment、Resource、ResourceLoader 等对象

• 调用 initMethod 方法： invokeInitMethod()

• 调用 BeanPostProcess 的后置处理方法：spring 的 aop 就是在这里实现的，AbstractAutoProxyCreator 

• 获取完成的对象，可以通过getBean 的方式来进行对象的获取

• 销毁流程： 

• 是否实现了 DispoableBean 接口

• 调用  destoryMethod 方法

Spring 循环依赖问题

什么是循环依赖？

A 依赖 B ，B 依赖 A ，Bean 创建过程中两个过程，实例化和初始化，在初始化中，有个属性赋值（此为重点）

• 创建 A 对象，实例化 A，此时 A 对象中的 b  属性为空
• 从容器中查找 B 对象，如果找到了，直接赋值，不存在循环依赖问题，找不到直接创建 B 对象
• 实例化 B 对象，此时 B 对象中的  a  属性为空，填充属性 a
• 从容器中查找 A 对象，找不到  ，直接创建，因此形成闭环

此时， A 对象已经存在，只不过A 对象不是一个完整的状态，只完成了实例化，但未初始化，如果在程序调用中拥有某个对象的引用，能否在后期完成赋值操作？可以优先把非完整状态的对象优先赋值，等待后续操作来完成赋值，相当于提前暴露了某个不完整对象的引用，所以解决问题的核心在于实例化与初始化分开操作，这也是解决循环依赖问题的关键。

三级缓存

所有的对象完成实例化与初始化后，需要将完整的对象放入 Spring 容器中，此时容器中对象存在的状态有一下两种，因此需要不同的 Map 结构来存储数据，缓存间的 map 互斥

• 一级缓存，存放完整对象

• 二级缓存，存放实例化未初始化对象

• 三级缓存：value 类型是一个 ObjectFactory，是一个函数式接口，存在的意义是保证在整个容器运行过程中，同名的 Bean 对象只有一个

• 普通对象与代理对象不能同时出现在容器中，因此当一个对象需要被代理时，就要使用代理对象覆盖掉之前的普通对象

• 当某个对象被调用时，优先判断此对象是否需要被代理，则执行函数，执行对象的覆盖过程

• 所有的 Bean 对象在创建的时候，要优先放置到三级缓存，在后续使用中，如果对象需要被代理，则返回代理对象，如果不需要被代理，则返回普通对象

缓存的放置和删除时间

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

BeanFactory 与 FactoryBean 有什么区别

相同点

• 都是用来创建 Bean 对象

不同点

• BeanFactory遵从严格的生命周期流程，复杂

• FactoryBean 接口

• isSingleton：是否是单例对象

• getObjectType：获取返回值类型

• getObject：自定义创建对象的过程（new 、反射、动态代理）

Spring 中用到的设计模式

• 单例模式：Bean 默认都是单例的
• 原型模式： 指定作用于为 prototype
• 工厂模式： BeanFactory
• 模板方法：postProcessBeanFactory
• 策略模式：XmlBeanDefinitionReader
• 观察者模式：listener、event
• 适配器模式：Adapter
• 责任链模式：使用 aop 的时候回先生成一个拦截器链
• 代理模式：动态代理
• 委托者模式：delegate

Spring AOP

• AOP 是 IOC 的一个扩展功能，先有 IOC,再有 AOP,只是在 IOC 整个流程中新增的一个扩展点：BeanPostProcessor

• Bean 的创建过程中有个步骤可以对 Bean 进行扩展，AOP 本身就是一个扩展功能，所以在BeanPostProcessor 的后置处理方法中来进行实现

• 代理对象的创建过程

• advice（通知）

• 切面

• 在哪些方法上进行切点

• 通过 JDK 或者 cglib 的方式来生成代理对象

• 执行方法调用的时候，会找到 DynamicAdvisoredInterceptor 类中的 intercept 方法，从此方法开始执行

• 根据之前定义好的通知来生成拦截器链

• 从拦截器链中以此获取每一个通知开始执行

Spring 事务回滚

Spring的事务管理是如何实现

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

• 准备工作：解析各个方法上事务相关的属性，根据具体的属性来判断是否开启新事务
• 当需要开启时，获取数据库连接，关闭自动提交，开启事务
• 执行具体的 sql 逻辑操作
• 在操作过程中，如果失败了，那么会通过 completeTransactionAfterThrowing 来完成事务的回滚，回滚的具体逻辑通过  doRollBack方法来实现，实现的时候也是先获取连接对象，然后通过连接对象来回滚
• 执行过程中，没有意外情况发生，通过 completeTransactionAfterReturning 来完成事务的提交，提交的具体逻辑是通过 doCommit 方法来实现，实现的时候先获取连接对象，然后通过对象进行提交
• 当事务执行完毕后，需要清理相关事务信息 ， cleanupTransactionInfo

Spring 事务传播

事务的传播特性指的是不用方法的嵌套调用过程中，事务应该如何进行处理，是用同一个事务还是不同事务，当出现异常的时候会回滚还是提交，两个方法之间的相关影响，在日常工作中，使用比较多的是：required、required_new、nested

• 事务分类

• 支持当前事务

• 不支持当前事务

• 嵌套事务

• 外 required ,内 required、required_new、nested

• 外 required_new ,内 required、required_new、nested

• 外 nested ,内 required、required_new、nested

核心处理逻辑

• 判断是否为同一个事务

• 是：异常统一在外层方法处理

• 不是：内层方法可能影响外层方法，但是外层方法是不会影响内层方法的