文章是对Spring一些基础的底层概念进行分析，后续再遇到这些问题的时候，可以采用这些步骤进行详细解释。
一.谈谈SpringIOC的理解，原理与实现?
总：
1.控制反转：
(1)原来的对象是由使用者来进行控制，有了Spring之后，可以把整个对象交给Spring来帮我们进行管理。
(2)它有一个依赖注入(DI)的概念：把对应的属性的值注入到具体对象中，可以通过@Autowired、@PopulateBean也可以完成属性值的注入。
2.容器：
(1)存储对象，使用Map结构进行存储，在Spring中一般存在三级缓存，SingletonObject存放完整的Bean对象，使用对象的时候通过SingletonObject获取;
(2)整个bean的生命周期从创建到使用到销毁的全部过程都是由容器来管理。
分：
1.一般谈IOC容器的时候要涉及到容器的创建过程(BeanFactory、DefaultListableBeanFactory)，容器它有一个最上层的根接口，叫做BeanFactory，它里面只是一个接口，没有提供对应的子类实现，我们在实际调用过程中，最最用普遍的就是一个DefaultListableBeanFactory，包括我们使用的时候也会优先创建当前的Bean工厂，创建Bean工程后会优先向Bean工厂中设置一些参数(BeanPostProcessor、Aware接口的子类)等等属性；
2.加载解析Bean对象，准备要创建的Bean对象的定义对象BeanDefinition(xml或者注解的解析过程)，因为只有解析后才能获取到完整的Bean对象，最终结果是获取到BeanDefinition对象；
3.BeanFactoryPostProcessor的处理，此处是扩展点(为什么Spring有一个完整的生态，发展的这么好，就是因为它提供了很多默认的扩展点，来帮助我们进行了很多点的扩充知识)，用的比较多的两个扩展点是PlaceHolderConfigurSupport、ConfigurationClassPostProcessor；
4.BeanPostProcessor的注册功能，方便后续对Bean对象完成具体的扩张功能；
(前四步完成后，代表BeanFactory准备的差不多了)
5.通过反射的方式将BeanDefinition对象实例化成具体的Bean对象；
6.Bean对象的初始化过程(填充数据、调用Aware子类的方法、调用BeanPostProcessor前置处理方法，调用init-method方法、调用BeanPostProcessor后置处理方法)；
7.生产完整的Bean对象，通过getBean方法可以直接获取；
8.销毁过程。
以上就是对IOC的整体理解，包含了一些详细处理过程，具体详细的逻辑需要看源码分析，但是总结一下，就是Spring中的Bean都是通过反射的方式生成的，同时其中包含了很多的扩展点，比如最常见的对BeanFactory的扩展、对Bean的扩展，除此之外，IOC中最核心的也就是填充具体Bean的属性和生命周期。
常见扩展点：自定义拦截器、获取Spring容器对象、全局异常处理、类型转换器、导入配置、项目启动时、修改BeanDefinition、初始化Bean前后、初始化方法、关闭容器前、自定义作用域。
二.谈谈SpringIOC的底层实现？
前言：其实上一个问题已经把底层实现说的差不多了，这里强调一点，在说到底层实现的时候，不是说把工作原理、过程、数据结构、流程、设计模式、设计思想这些都说出来，而且只需要说出自己对它的理解和了解过的实现过程即可。
比较重要的几个点是反射，工厂(BeanFactory)，设计模式；
几个关键的方法如下：
CreatBeanFactory、getBean、doGetBean、createBean、doCreateBean，createBeanInstance(getDeconstructor、newInstance)、populateBean，initiializingBean
这些方法如果加了do的方法就是实际干活的方法，不加do的只是在前面套了一层，仅此而已。
简单流程如下：
1.先通过CreatBeanFactory创建出一个Bean工厂(DefaultListableBeanFactory)；
2.开始循环创建对象，因为容器中的Bean默认都是单列的，所以优先通过getBean，doGetBean从容器中查找；
3.(第二步没有找到Bean)通过createBean、doCreateBean方法，以放射的方式创建对象，一般情况下使用的是无参的构造方法(getDeconstructor、newInstance)；
4.进行对象的属性填充(populateBean)；
5.进行其他的初始化操作(initiializingBean)。
三.谈谈Bean的生命周期？
记住下图流程即可：
但是在表述的时候，不要只谈图中的关键点，要能扩展描述，比较图相当于骨架，需要加点肉。
1.实例化Bean对象：反射的方式生成对象；
2.设置对象属性：populateBean()，循环依赖(三级缓存)问题；
3.检查Aware相关接口并设置相关方法：invokeAwareMethod(完成BeanName、BeanFactory、BeanClassLoader对象的属性设置)；
4.调用BeanPostProcessor中的前置处理方法：使用较多的有ApplicationContextPostProcessor(设置ApplicationContext、Environment、ResourceLoad、EmbeddValueResolver对象)；
- 调用initmethod方法：invokeInitmethod()，判断是否实现了initializingBean接口，如果有，调用afterPropertiesSet方法，没有就不调用；
6.调用BeanPostProcessor中的后置处理方法：Spring的Aop就是在此处实现的，AbstractAutoProxyCreator；
7.注册Destuction相关的回调接口(钩子函数)；
8..获取到完整的对象，可以通过getBean的方法来进行对象的获取，
9.销毁流程：(1)判断是否实现了DispoableBean接口，(2)调用DestroyMethod方法。(容器关闭的时候销毁)
四.谈谈Spring是如何解决循环依赖的问题的?
突出几个重要名词：三级缓存、提前暴露对象、Aop
总：
什么是循环依赖问题 ----- > A依赖B，B依赖A，A对象里面引用了B属性，B对象里面引用了A数据，相互引用构成闭环，就会出现循环依赖问题。
分：
先说明Bean的创建过程：实例化、初始化(填充属性)，流程图如下：
1.先创建A对象，实例化A对象，此时A对象中的B属性为空，填充属性B；
2.从容器中查找B对象，如果找到了直接赋值，不存在循环依赖问题，找不到直接创建B对象；
3.实例化B对象，此时B对象中的A属性为空，填充数据A；
4.从容器中查找A对象，找不到，直接创建。
上面四个步骤是形成闭环的原因。
此时，如果仔细琢磨，会发现A对象是存在的，只不过此时的A对象不是一个完整的状态，只完成了实例化，但是未完成初始化，如果在程序的调用过程中，拥有了某个对象的引用，其实是可以在后期给它完成赋值操作，所以可以优先把一个非完整状态的对象优先赋值，等待后续操作来完成赋值，相当于提前暴露了某个不完整对象的引用，所以解决问题的核心在于实例化和初始化分开操作，这也是解决循环依赖问题的关键。
当所有的对象都完成实例化和初始化操作之后，还要把完整对象放到容器中，此时在容器总存在两个对象(完成实例化但未完成初始、完整状态)，因为都在容器中，所以要使用不同的Map结构来进行存储，此时就有了一级缓存和二级缓存，因为它们是互斥关系，所以，如果一级缓存中有了，那么二级缓存中就不会存在同名的对象，因为他们的查询顺序是一级、二级、三级的方式来进行查找的。一级缓存中放的是完整对象，二级缓存中放的是非完整对象。
那为什么还需要三级缓存？
因为三级缓存的Value类型是ObjectFactory，是一个函数式接口，存在的意义是保证在整个容器的运行过程中同名的Bean对象只能有一个。
如果一个Bean对象需要被代理，或者说需要生成代理对象，是需要优先生成一个普通对象，再生成代理对象的，那么此时既有普通对象，又有代理对象，先使用哪个对象就是一个问题。
其实普通对象和代理对象是不能同时出现在容器中的，因此当一个对象需要被代理的时候，就要使用代理对象覆盖掉之前的普通对象，在实际的调用过程中，是没有办法确定什么时候对象被使用，所以就要求当某个对象被调用的时候，优先判断此对象是否需要被代理，类似于一种回调机制的实现，因此传入lambda表达式的时候，可以通过lambda表达式来执行对象的覆盖过程，使用getEarlyBeanReference()方法；
因此，所有的Bean对象在创建的时候都需要优先放在三级缓存中，在后续的使用过程中，如果需要被代理则返回代理对象，如果不需要被代理，直接返回普通对象。
缓存的放置时间和删除时间：
三级缓存：createBeanInstance之后(addSingletonFactory)；
二级缓存：第一次从三级缓存确定对象是代理对象还是普通对象的时候，同时删除三级缓存(getSingleton)；
一级缓存：生成完整对象之后放到一级缓存，然后删除二三级缓存(addSingleton)。
五.谈谈Bean Factory与FactoryBean有什么区别?
相同点：都是用来创建Bean对象的；
不同点：使用BeanFactory创建对象的时候，必须要遵守严格的生命周期流程，太复杂了，如果想简单的自定义某个对象的创建，同时创建完成的对象交给Spring来管理，那么就需要实现FactoryBean接口了。
FactoryBean接口有如下几种方法：
isSingleton：是否是单列对象；
getObjectType：获取返回对象的类型；
getObject：自定义创建对象的过程(new、反射、动态代理)
两者相当于一个是复杂版，一个是简化版创建Bean，并且创建完成以后都交给Spring来管理。
六.谈谈Spring中用到的设计模式?
单例模式：Bean默认都是单列的；
原型模式：指定作用域为prototype；
工厂模式：BeanFactory；
模版方法：postProcessBeanFactory、onRefresh、initPropertyValue；
策略模式：XmlBeanDefinitionReader，PropertiesBeanDefinitionReader；
观察者模式：listerner，event，multicast；
适配器模式：Adapter；
装饰者模式：BeanWrapper；
责任链模式：使用AOP的时候会先生成一个拦截器链；
代理模式：动态代理；
委托者模式：delegate；
。。。。。。。。。。
七.谈谈Spring的AOP的底层实现原理?
Aop是Ioc的一个扩展功能，先有得Ioc，再有的Aop，只是在Ioc的整个流程中新增的一个扩展点而且，BeanPostProcessor。
总：
Aop概念、应用场景、动态代理；
分：
Bean的创建过程中有一个步骤可以对Bean进行扩展实现，Aop本身就是一个扩展功能，所以在BeanPostProcessor的后置处理方法中来进行实现。
实现过程：
1.代理对象的创建过程(advice、切面、切点)；
2.通过jdk(反射)或者cglib(生产代理类的字节码)的方法来生成代理对象；
3.在执行方法调用的时候，会调用到生成的字节码文件中，直接会找到DynamicAdvisoredInterceptor类中的intercept方法，从此方法开始执行；
4.根据之前定义好的通知，生产拦截器链；
5.从拦截器链中依次回去每一个通知开始进行执行，在执行过程中，为了方便找到下一个通知是哪个，会有一个InvocationInterceptor对象，找到时是从-1的位置依次开始查找并且执行的。
八.谈谈Spring的事务是如何回滚的?
其实也就是谈谈Spring的事务管理是如果实现的。
分析：
其实Spring事务都是通过Aop来实现的，也是Aop的一个重要应用场景，Spring里面提供了申明式事务和编程式事务，编程式事务用的很少，一般的都是用的申明式事务；其实Aop理解清楚了，事务也就理解清楚了，我们在做Aop的时候，里面有addBefore、addAfter等多种advice操作，那么我们想自定义事务怎么实现(先不管Spring是怎么实现的)？先来看一个数据库事务：
如果"进行sql操作"放在Spring事务中，相当于就是"业务逻辑"操作，如下图：
这个自定义事务就必须定义好before、after、around，还需要定义一个afterThrowing才能实现这个逻辑，这样其实挺麻烦的，有办法将它们全部合并在一个东西里面吗？那就是Spring事务。
总：
Spring的事务是由Aop来实现的，首先要根据具体的代理对象，然后按照Aop的整套流程来执行具体的操作逻辑，正常情况下要通过通知来完成核心功能，但是事务不是通过通知来实现的，而是通过一个TransactionIntercepter来实现的，然后调用invoke来实现具体的逻辑。
分：
1.先做准备工作，解析各个方法上事务相关的属性，根据具体的属性来判断是否开启新事物；
2.当需要开启的时候，获取数据库连接，关闭自动提交功能，开启事务；
3.执行Sql的逻辑的操作；
4.在操作过程中，如果执行失败了，那么会通过completeTransactionAfterThrowing来完成事务的回滚操作，回滚的具体逻辑是通过doRollBack的方实现的，实现的时候也是需要先获取连接，通过连接对象回滚；
5.如果执行过程中，没有任何意外情况发生，那么通过completeTransactionAfterReturning来完成事务的提交操作，提交的具体逻辑是通过doCommit方法来实现的，实现的时候也是通过先获取连接，通过连接来提交事务；
6.当事务执行完毕之后，需要清除相关的事务信息cleanupTransactionInfo。
九.谈谈Spring事务传播?
事务有七中传播特性：
1.Required：如果当前存在事务，则加入该事务，如果不存在事务，则创建一个事务；
2.Requires_new：总是创建一个新的事务，如果当前存在事务，则挂起当前事务；
3.nested：如果当前存在事务，则在当前事务中创建一个新的嵌套事务；如果当前没有事务，则创建一个新的事务；
4.Support：如果当前存在事务，则加入该事务，如果不存在事务，则创建一个事务；
5.Not_Support：以非事务方式执行操作，如果当前存在事务，则挂起当前事务；
6.Never：以非事务方式执行操作，如果当前存在事务，则抛出异常；
7.Mandatory：如果当前存在事务，则加入到当前事务中；如果当前没有事务，则抛出异常。
某一事物嵌套另一个事物的时候怎么办？比如：A方法调用B方法，AB方法都有事务，并且传播特性不同，那么A如果有异常，B怎么办，B如果有异常，A怎么办?
总：
事务的传播特性指的是不同方法的嵌套调用过程中，事务应该如何进行处理，是用同一个事务还是不同的事务，当出现异常的时候事务会回滚还是提交，两个方法之间的相关影响的关系是什么，在日常工作中，使用比较多的是Required、Requires_new、nested。
分：
1.根据事务的分类不同，可以分为三类：
(1)支持当前事务(Required、Mandatory、Support)；
(2)不支持单当前事务(Requires_new、Never、Not_Support)；
(3)嵌套事务(nested)；
2.如果外层方法是required，内层方法是，required,requires_new,nested，事务怎么传播；
3.如果外层方法是requires_new，内层方法是，required,requires_new,nested，事务怎么传播；
4.如果外层方法是nested，内层方法是，required,requires_new,nested，事务怎么传播；