Spring是一个容器框架，是个生态，是基石，用来封装JavaBean对象，中间层框架（万能胶），起到一个连接作用，比如Struct和hibernate粘合在一起运用

得益于IOC容器，采用注册式单例，始终在map中保持了实例的引用地址
只要IOC容易不被销毁，bean 就永远存在
spring 帮我们做了new 的动作，然后把实例管理起来了

IOC： 是一个容器，帮我们管理所有的组件
1)依赖注入，使用@Autowired注解，自动赋值
2)某个组件要使用Spring提供的更多(IOC,AOP),必须加到容器中
1)容器启动，创建所有单实例bean
2)@Autowired自动装配的时候，是从容器中找到这些bean的
4)容器中包括了所有的bean
5)容器就是一个map,这个map中保存了所有创建好的bean，并提供外界获取功能
①基于注解的AOP步骤：
c.在切面类中使用5个通知注解来配置切面中的这些方法何时何地运行
d.开启基于注解的aop功能
②基于配置的AOP步骤：

Resource是j2ee的注解，扩展性强，换了一个容器框架也能使用,通过name来找bean

5.依赖注入的方式有几种，各是什么?

对象的初始化，可以调用init-method指定初始化方法，对于单例的只会在servlet加载的时候初始化
对象的销毁，可以指定销毁方法，destroy-method ，只针对单列模式，prototype不会被管理

spring事务只有捕获到异常才会终止或回滚，如果你在程序中try/catch后自己处理异常而没有throw，那么事务将不会终止或回滚，失去事务本来的作用；
spring事务本质上使用数据库锁；
spring事务只有在方法执行过程中出现异常才会回滚，并且只回滚数据库相关的操作；

对象锁和spring事务的对比(既然数据库支持事务机制，为什么spring还需要事务支持？)：
对象锁可以保证数据一致性和业务逻辑正确性，但不能保证并发性；
spring事务不能严格保证数据一致性和业务逻辑正确性，但具有较好的并发性，因为只锁数据库行数据；
spring事务为什么不能保证数据一致性和业务逻辑正确性：
1)如果事务方法抛异常，此时会回滚数据库操作，但已经执行的其他方法不会回滚，因此无法保证业务逻辑正确性；
2)即使事务方法不抛异常，也不能保证数据一致性（因为事务接口里的数据库操作在整个接口逻辑执行结束后才提交到数据 库，在接口最后提交到数据库的前后很有可能带来数据一致性的问题），从而不能保证业务逻辑正确性；

思考：某一个事务嵌套另一个事务的时候怎么办？
A方法调用B方法，AB都有事务，并且传播特性不同，如果A出现异常，B怎么办；B如果出现异常，A怎么办？
总：事务的传播特性指的是不同方法的嵌套调用过程中，事务应该如何进行处理，是用同一个事务还是不同事务，当出现异常时是会回滚还是提交，两个方法之间的相关影响，一般用的较多的是：required，required_new,nested
分：①事务分类：支持当前事务，不支持当前事务，嵌套事务
①1.判断内外方法是否是同一个事务：
是：异常统一在外层方法处理
不是：内层方法有可能影响到外层方法，但外层方法不会影响内存方法

10.Spring事务的隔离级别？（5种）
Spring事务管理是如何实现的？
总： spring事务是由aop来实现的，首先要生成具体的代理对象，然后按照aop的整套流程来执行具体的操作逻辑，正常情况下要通过通知来完成核心功能，但是事务不是通过通知来实现的，而是通过一个TransactionInterceptpr来实现的，然后调用invoke来实现具体的逻辑
①先做准备工作，解析各个方法上事务相关的属性，根据具体的属性来判断是否开启新事务
②当需要开启时，获取数据库连接，关闭自动提交功能，开启事务
④在操作过程中，如果执行失败了，那么会通过completeTransactionAfterThrowing来完成事务的回滚操作，回滚的具体逻辑是通过doRollback方法来实现的，实现的时候也要获取连接对象，通过连接对象来回滚
⑤如果执行过程中，没有任何意外情况发生，那么通过commitTransactionAfterReturning来完成事务的提交操作，提交的具体逻辑是通过docommit方法来实现的，实现的时候也是要获取连接，通过连接对象来提交
前置通知 记录日志(方法将被调用)
环绕通知 控制事务 权限控制
后置通知 记录日志(方法已经成功调用)
异常通知 异常处理 控制事务
最终通知 记录日志(方法已经调用，但不一定成功)

1)BeanFactory：是Spring里面最底层的接口，包含了各种Bean的定义，读取bean配置文档，管理bean的加载、实例化，控制bean的生命周期，维护bean之间的依赖关系。ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，还提供了更完整的框架功能：
②统一的资源文件访问方式。
③提供在监听器中注册bean的事件。
④同时加载多个配置文件。
⑤载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层。
2)①BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。
ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
②ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
③相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。

总：aop的概念，应用场景，动态代理
分：bean的创建过程中有一个步骤可以对bean进行扩展实现，aop本身是一个扩展功能，所以在BeanPostProcessor的后置处理方法中进行实现：
①代理对象的创建过程（advice，切面，切点）
②通过jdk或cglib的方式生成代理对象
③在执行方法调用的时候，会调用到生成的字节码文件中，直接会找到DynamicAdvisoredInterceptor类中的intercept方法，从此方法开始执行
④根据之前定义好的通知生成拦截器链
⑤从拦截器链中依次获取每一个通知开始进行执行，在执行过程中，为了方便找到下一个通知是哪一个，会有一个cglibMethodInvocation的对象，找的时候从-1的位置依次开始查找并且执行的
三级缓存、提前暴露对象、aop
总： ①什么是循环依赖问题，A依赖B,B依赖A
分： 先说明bean的创建过程，实例化、初始化（填充属性）
①先创建A对象，实例化A对象②③④

7.SpringMVC的控制器是不是单例模式,如果是,有什么问题,怎么解决？
非WEB环境：直接在main方法或者是junit测试方法中通过new操作来创建.
WEB 环境：我们希望SpringIOC容器在WEB应用服务器启动时就被创建.
并且将容器对象绑定到ServletContext中， 让所有的web组件能共享到IOC容器对象.