今日份鸡汤：无论这个世界对你怎样，都请你一如既往的努力、勇敢、充满希望。
今天感恩节，愿我们都能够知恩、感恩，愿我们每个人都是温暖的人，都能够被温柔以待~
1、Spring是什么？
轻量级的开源的J2EE框架，他是一个容器框架，用来装JavaBean（java对象），中间层框架（万能胶），可以起一个连接作用，比如说把Struts和Hibernate粘合在一起运用，可以让我们的企业开发更快、更简洁。
Spring是一个轻量级的控制反转（IOC）和面向切面（AOP）的容器框架。
（1）从大小与开销两方面而言Spring都是轻量级的。
（2）通过控制反转（IOC）的技术达到松耦合的目的。
（3）提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务进行内聚性的开发。
（4）包含并管理应用对象（Bean）的配置和生命周期，这个意义上是一个容器。
（5）将简单的组件配置、组合成为复杂的应用，这个意义上是一个框架。
2、谈谈你对IOC的理解
容器概念、控制反转、依赖注入
IOC容器：
实际上就是个map(key, value)，里面存的是各种对象（在XML里配置的bean节点、@Repository、@Service、@Controller、@Component），在项目启动的时候会读取配置文件里面的bean节点，根据全限定类名使用反射穿件对象放到map里、扫描到打上上述注解的类还是通过反射创建对象放到map里。
这个时候map里就有各种对象了，接下来我们就在代码里需要用到里面的对象时，再通过DI注入（Autowired、Resource等注解，xml里bean节点内的ref属性，项目启动的时候会读取xml节点ref属性根据id注入，也会扫描这些注解。根据类型或id注入，id就是对象名）。
控制反转：
没有引入IOC容器之前，对象A依赖于对象B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象B，无论是创建还是使用对象B，控制权都在自己手上。
引入IOC容器之后，对象A与对象B之间失去了直接联系，当对象A运行到需要对象B的时候，IOC容器会主动创建一个对象B注入到对象A需要的地方。
通过前后的对比，不难看出来：对象A获得依赖对象B的过程，由主动行为变为被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。
全部对象的控制权全部上缴给“第三方”IOC容器，所以，IOC容器成了整个系统的关键核心，它起到了一种类似“粘合剂”的作用，把系统中的所有对象粘合在一起发挥作用，如果没有这个“粘合剂”，对象与对象之间会彼此失去联系，这就是有人把IOC容器比喻成“粘合剂”的由来。
依赖注入：
获得依赖对象的过程被反转了，控制被反转之后，获得依赖对象的过程由自身管理变为了由IOC容器主动注入。依赖注入是实现了IOC的方法，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中。
Spring容器根据XML配置或者注解，去实例化bean对象，同样根据XML配置或者注解去对Bean对象间的引用关系，去进行依赖注入，实现某个Bean依赖了另外一个bean。
底层核心技术就是通过反射实现的。
举个例子：
一个系统里面，几十个类都使用了UserService userService = new UserServiceImpl()，当有一天这个实现类不再是UserServiceImpl，比如换成了CustomerServiceImpl
未使用spring管理Bean对象的时候：
这十几个类里面代码就都需要将UserService userService = new UserServiceImpl() 更改为 UserService userService = new CustomerServiceImpl()，有可能你有漏掉哪块代码，就都会出问题。因为这个时候，对象与对象间的依赖关系，完全是靠对象自己去注入的。
使用spring管理Bean对象的时候：
我们只需要将UserServiceImpl中@Service注解去掉，同时CustomerServiceImpl类实现UserService接口，并且增加@Service注解即可，因为这个时候，对象与对象间的依赖关系，不再是靠对象自己去注入，而是把控制权交给了Spring的容器，由容器帮助我们来完成对象间的依赖注入。
3、谈谈你对AOP的理解
系统是由许多不同的组件所组成的，每一个组件各负责一块特定功能。除了实现自身核心功能之外，这些组件还经常承担着额外的职责。例如日志、事务管理和安全这样的核心服务经常融入到自身具有核心业务逻辑的组件中去，这些系统服务经常被称为横切关注点，因为他们会跨越系统的多个组件。
当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力，也就是说，OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系，例如日志功能。
日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。
在OOP设计中，它导致了大量代码的重复，而不利于各个模块的重用。
AOP：将程序中的交叉业务逻辑（比如安全、日志、事务等），封装成一个切面，然后注入到目标对象（具体业务逻辑）中去，AOP可以对某个对象或某些对象的功能进行增强，比如对象中的方法进行增强，可以在执行某个方法之前额外的做一些事情，在某个方法执行之后额外的做一些事情。
4、BeanFactory和ApplicationContext有什么区别？
ApplicationContext是BeanFactory的子接口。
ApplicationContext提供了更完整的功能。
（1）继承MessageSource，因此支持国际化。
（2）统一的资源文件访问方式。
（3）提供在监听器中注册bean的事件。
（4）同时加载多个配置文件。
（5）载入多个（有继承关系）上下文，使得每一个上下文都专注于一个特定的层次，比如应用的web层。
BeanFactory采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean（调用getBean（）），才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFactory加载后，直至第一次使用调用getBean方法才会抛出异常。
ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例Bean，确保当你需要的时候，你就不用等待，因为它们已经创建好了。
相对于基本的BeanFactory，ApplicationContext唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。
BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用ContextLoader。
BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者间的区别是：BeanFactory需要手动注册，ApplicationContext则是自动注册。
5、描述一下Spring Bean的生命周期
（1）解析类得到BeanDefinition。
（2）如果有多个构造方法，则要推断构造方法。
（3）确定好构造方法后，进行实例化得到一个对象。
（4）对对相中的加了@Autowired注解的属性进行属性填充。
（5）回调Aware方法，比如BeanNameAware、BeanFactoryAware。
（6）调用BeanPostProcessor的初始化前的方法。
（7）调用初始化方法。
（8）调用BeanPostProcessor的初始化后的方法，在这里会进行AOP。
（9）如果当前创建的Bean是单例的，则会把Bean放入单例池。
（10）使用Bean。
（11）Spring容器关闭时调用DisposableBean中destory（）方法。
6、解释下Spring支持的几种Bean的作用域
（1）singleton：默认，每个容器中只有一个Bean的实例，单例的模式由BeanFactory自身来维护，该对象的生命周期是与Spring IOC容器一致的（但在第一次被注入时才会创建）。
（2）prototype：为每一个Bean请求提供一个实例。在每次注入时都会创建一个新的对象。
（3）request：Bean被定义为在每个HTTP请求中创建一个单例对象，也就是说在单个请求中都会复用这一个单例对象。
（4）session：与request范围类似，确保每个session中有一个bean的实例，在session过期后，bean会随之失效。
（5）application：Bean被定义为在servletContext的生命周期中复用一个单例对象。
（6）websocket：bean被定义为在websocket的生命周期中复用一个单例对象。
（7）global-session：全局作用域，global-session和Portlet应用相关，当你的应用部署在Portlet容器中工作时，它包含很多Portlet。如果你想要的声明让所有的Portlet共用全局的存储变量的话，那么这全局变量需要存储在global-session中。全局作用域与Servlet中的session作用域效果相同。
7、Spring框架中的单例Bean是线程安全的吗？
Spring中的Bean默认是单例模式的，框架并没有对Bean进行多线程的封装处理。
如果Bean是有状态的，那就需要开发人员自己来进行线程安全的保证，最简单的办法就是改变Bean的作用域，把“singleton”改为“prototype”，这样每次请求Bean就相当于是new Bean（）这样就可以保证线程的安全了。
有状态就是有数据存储功能。
无状态就是不会保存数据。Controller、service和dao层本身并不是线程安全的，只是如果只是调用里面的方法，而且多线程调用一个实例的方法，会在内存中复制变量，这是自己的线程的工作内存，是安全的。
Dao会操作数据库Connection，Connection是带有状态的，比如说数据库事务，spring的事务管理器使用Threadlocal为不同线程维护了一套独立的Connection副本，保证线程之间不会相互影响（spring是如何保证事务获取同一个connection的）
不要再bean中声明任何有状态的实例变量或类变量，如果必须如此，那么就使用ThreadLocal把变量变为线程私有的，如果bean的实例变量或类变量需要在多个线程之间共享，那么就只能使用synchronized、lock、CAS等这些实现线程同步的方法了。
8、Spring框架中用到了哪些设计模式？
（1）简单工厂：由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。
Spring中的BeanFactory就是简单工厂模式的提现，根据传入一个唯一的标识来获得Bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。
（2）工厂方法：实现了FactoryBean接口的bean是一类叫做factory的bran，其特点是，spring会在使用getBean（）调用获得该bean时，会自动调用该bean的getObject（）方法，所以返回的不是factory这个bean，而是这个bean.getObject（）方法的返回值。
（3）单例模式：保证一个类仅有一个实例，并提供一个访问它的全局访问点。Spring对单例的实现，spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory，但没有从构造器级别去控制单例，这是因为spring管理的是任意的java对象。
（4）适配器模式：spring定义了一个适配接口，使得每一种controller有一种对应的适配器实现类，让适配器代替controller执行相应的方法，这样在扩展controller时，只需要增加一个适配器类就完成了springMVC的扩展了。
（5）装饰器模式：动态地给一个对象添加一些额外的职责，就增加功能来说，Decorator模式相比生成子类更为灵活。Spring中用到的包装器模式在类名上有两种表现，一种是类名中含有wrapper，另一种是类名中含有Decorator。
（6）动态代理：切面在应用运行的时候被织入，一般情况下，在织入切面时，AOP容器会为目标对象动态的创建一个对象，SpringAOP就是以这种方式织入切面的。
织入：把切面应用到目标对象并创建新的代理对象的过程。
（7）观察者模式：spring的事件驱动模型使用的是观察者模式，spring中observer模式常用的地方就是listener的实现。
（8）策略模式：spring框架的资源访问resource接口，该接口提供了更强的资源访问能力，spring框架本身大量使用了resource接口来访问底层资源。
9、Spring事务的实现方式和原理以及隔离级别？
在使用spring框架时，可以有两种使用事务的方式，一种是编程式的，一种是申明式的，@Transaction注解就是申明式的。
首先，事务这个概念是数据库层面的，Spring只是基于数据库中的事务进行了扩展，以及提供了一些能让程序员更加方便操作事务的方式。
比如我们可以通过在某个方法上增加@Transaction注解，就可以开启事务，这个方法中所有的sql都会在一个事务中执行，统一成功或失败。
在一个方法上加了@Transaction注解后，spring会基于这个类生成一个代理对象，会将这个代理对象作为bean，当在使用这个代理对象的方法时，如果这个方法上存在@Transaction注解，那么代理逻辑会先把事务的自动提交设置为false，然后再去执行原本的业务逻辑方法，如果执行业务逻辑方法没有出现异常，那么代理逻辑中就会将事务进行提交，如果执行业务逻辑方法出现了异常，那么则会将事务进行回滚。
当然，针对哪些异常回滚事务是可以配置的，可以利用@Transaction注解中的rollbackFor属性进行配置，默认情况下会对RuntimeException和Error进行回滚。
Spring事务隔离界别就是数据库的隔离级别：外加一个默认级别
（1）read uncommitted（未提交读）
（2）Read committed（提交读、不可重复读）
（3）Repeatable read（可重复读）
（4）Serializable（可串行化）
数据库的配置隔离级别是 Read Commited，而spring配置的隔离级别是repeatable read，请问这时隔离级别是以哪个为准？以spring配置的为准，如果spring设置的隔离级别数据库不支持，效果取决于数据库。
10、spring事务传播机制
多个事务方法相互调用时，事务如何在这些方法间传播？
方法A是一个事务方法，方法A执行过程中调用了方法B，那么方法B有无事务以及方法B对事务的要求不同都会对方法A的事务具体制定造成影响，同事方法A的事务对方法B的事务执行也有影响，这种影响具体是什么就由两个方法所定义的事务传播类型所决定。
REQUIRED（spring默认的事务传播类型）：如果当前没有事务，则自己新建一个事务，如果当前存在事务，则加入这个事务。
SUPPORTS:当前存在事务，则加入当前事务，如果当前没有事务，就以非事务方法执行。
MANDATORY:当前存在事务，则加入当前事务，如果当前事务不存在，则抛出异常。
REQUIRES_NEW：创建一个新事务，如果存在当前事务，则挂起该事务。
NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，则挂起当前事务。
NEVER:不使用事务，如果当前事务存在，则抛出异常。
NESTED：如果当前事务存在，则在嵌套事务中执行，否则REQUIRED的操作一样（开启一个事务）
和REQUIRES_NEW的区别
REQUIRES_NEW是新建一个事务并且新开启的这个事务与原有的事务无关，而NESTED则是当前存在事务时（我们把当前事务称之为父事务），会开启一个嵌套事务（称之为一个子事务），在NESTED情况下父事务回滚时，子事务也会回滚，而在REQUIRES_NEW情况下，原有事务回滚，不会影响新开启的事务。
和REQUIRED的区别
REQUIRED情况下，调用方存在事务时，则被调用方和调用方使用同一事务，那么被调用方出现异常时，由于共用了一个事务，所以无论调用方是否catch其异常，事务都会回滚，而在NESTED情况下，被调用方发生异常时，调用方可以catch其异常，这样只有子事务回滚，父事务不受影响。
11、spring事务什么时候会失效？
Spring事务的原理是AOP，进行了切面增强，那么失败的根本原因是这个AOP不起作用了！常见情况有如下几种：
（1）发生自调用，类里面使用this调用本类的方法（this通常省略），此时这个this对象不是代理类，而是UserService对象本身！
解决办法很简单，让那个this变成UserService的代理类即可！
（2）方法不是public的
@Transactional 只能用于public的方法上，否则事务不会失效，如果要用在非public方法上，可以开启AspectJ 代理模式。
（3）数据库不支持事务。
（4）没有被spring管理。
（5）异常被吃掉，事务不会回滚（或者抛出的异常没有被定义，默认为RuntimeException）。
12、什么是bean的自动装配，有哪些方式？
开启自动装配，只需要在XML配置文件
Autowire属性有五种装配的方式：
（1）no-缺省情况下，自动配置是通过“ref”属性手动设定。
手动装配：以value或者ref的方式明确指定属性值都是手动装配。需要通过‘ref’属性来连接bean。
（2）byName-根据bean的属性名称进行自动装配。
Customer的属性名称是person，spring会将bean id为person的bean通过setter方法进行自动装配
（3）byType-根据bean的类型进行自动装配
Customer的属性person的类型为Person，spring会将Person类型通过setter方法进行自动装配。
（4）constructor-类似byType，不过是应用于构造器的参数，如果一个bean与构造器参数的类型相同，则进行自动装配，否则导致异常。
Customer构造函数的参数person的类型为Person，spring会将Person类型通过构造方法进行自动装配。
（5）autodetect-如果有默认的构造器，则通过constructor方式进行自动装配，否则使用byType方式进行自动装配。
如果有默认的构造器，则通过constructor方式进行自动装配，否则使用byType方式进行自动装配。
@Autowired自动装配bean，可以在字段、setter方法、构造函数上使用。
13、spring boot、spring mvc 和 spring有什么区别？
Spring是一个IOC容器，用来管理bean，使用依赖注入实现控制反转，可以很方便的整合各种框架，提供AOP机制弥补OOP的代码重复问题、更方便将不同类不同方法中的共同处理抽取成切面、自动注入给方法执行，比如日志、异常等。
Springmvc是spring对web框架的一个解决方案，提供了一个总的前端控制器servlet，用来接收请求，然后定义了一套路由策略（url到handle的映射）及适配执行handle，将handle结果使用视图解析技术生成视图展现给前端。
Springboot是spring提供的一个快速开发工具包，让程序员能够更方便、更快速的开发spring+springmvc应用，简化了配置（约定了默认配置），整合了一系列的解决方案（starter机制）、redis、mongodb、es，可以开箱即用。
14、springMVC工作流程
（1）用户发送请求至前端控制器DispatcherServlet。
（2）DispatcherServlet 收到请求调用 HandlerMapping处理器映射器。
（3）处理器映射器找到具体的处理器（可以根据xml配置、注解进行查找），生成处理器及处理器拦截器（如果有则生成）--并返回给DispatcherServlet。
（4）DispatcherServlet 调用 HandlerAdapter处理器适配器。
（5）HandlerAdapter经过适配调用具体的处理器（Controller，也叫后端控制器）。
（6）Controller执行完成返回ModelAndView。
（7）HandlerAdapter 将 controller执行结果ModelAndView返回给DispatcherServlet。
（8）DispatcherServlet将ModelAndView传给ViewReslover 视图解析器。
（9）ViewReslover 解析后返回具体view。
（10）DispatcherServlet 根据view进行渲染视图（即将模型数据填充至视图中）。
（11）DispatcherServlet 响应用户。