Spring

两大特性IOC、AOP

SpringIOC

Inversion of Control（IoC）是面向对象中的一种编程思想或原则。所谓IoC，对于spring框架来说，就是由spring来负责控制对象的生命周期和对象间的关系。从此在开发过程中不再需要关注对象的创建和生命周期的管理，而是在需要时由Spring框架提供，这个由spring框架管理对象创建和生命周期的机制称之为控制反转。而在创建对象的过程中Spring可以依据配置对对象的属性进行设置，这个过程称之为依赖注入,也即DI。

IOC（Inversion of Control）：控制反转
DI（Dependency Injection）：依赖注入
IOC是一种思想，而DI是实现IOC的主要技术途径。
DI主要有两种注入方式，及Setter注入和构造器注入。

为什么需要Ioc

实际上，IoC 是为了屏蔽构造细节。例如 new 出来的对象的生命周期中的所有细节对于使用端都是知道的，如果在没有 IoC 容器的前提下，IoC 是没有存在的必要，不过在复杂的系统中，我们的应用更应该关注的是对象的运用，而非它的构造和初始化等细节。

Spring Bean 的生命周期

生命周期：

1. Spring Bean 元信息配置阶段，可以通过面向资源（XML 或 Properties）、面向注解、面向 API 进行配置

2. Spring Bean 元信息解析阶段，对上一步的配置元信息进行解析，解析成 BeanDefinition 对象，该对象包含定义 Bean 的所有信息，用于实例化一个 Spring Bean

3. Spring Bean 元信息注册阶段，将 BeanDefinition 配置元信息 保存至 BeanDefinitionRegistry 的 ConcurrentHashMap 集合中

4. Spring BeanDefinition 合并阶段，定义的 Bean 可能存在层次性关系，则需要将它们进行合并，存在相同配置则覆盖父属性，最终生成一个 RootBeanDefinition 对象

5. Spring Bean 的实例化阶段，首先的通过类加载器加载出一个 Class 对象，通过这个 Class 对象的构造器创建一个实例对象，构造器注入在此处会完成。在实例化阶段 Spring 提供了实例化前后两个扩展点（InstantiationAwareBeanPostProcessor 的 postProcessBeforeInstantiation、postProcessAfterInstantiation 方法）

6. Spring Bean 属性赋值阶段，在 Spring 实例化后，需要对其相关属性进行赋值，注入依赖的对象。首先获取该对象所有属性与属性值的映射，可能已定义，也可能需要注入，在这里都会进行赋值（反射机制）。提示一下，依赖注入的实现通过 CommonAnnotationBeanPostProcessor（@Resource、@PostConstruct、@PreDestroy）和 AutowiredAnnotationBeanPostProcessor（@Autowired、@Value）两个处理器实现的。

7. Aware 接口回调阶段，如果 Spring Bean 是 Spring 提供的 Aware 接口类型（例如 BeanNameAware、ApplicationContextAware），这里会进行接口的回调，注入相关对象（例如 beanName、ApplicationContext）

8. Spring Bean 初始化阶段，这里会调用 Spring Bean 配置的初始化方法，执行顺序：@PostConstruct 标注方法、实现 InitializingBean 接口的 afterPropertiesSet() 方法、自定义初始化方法。在初始化阶段 Spring 提供了初始化前后两个扩展点（BeanPostProcessor 的 postProcessBeforeInitialization、postProcessAfterInitialization 方法）

9. Spring Bean 初始化完成阶段，在所有的 Bean（不是抽象、单例模式、不是懒加载方式）初始化后，Spring 会再次遍历所有初始化好的单例 Bean 对象，如果是 SmartInitializingSingleton 类型则调用其 afterSingletonsInstantiated() 方法，这里也属于 Spring 提供的一个扩展点

10. Spring Bean 销毁阶段，当 Spring 应用上下文关闭或者你主动销毁某个 Bean 时则进入 Spring Bean 的销毁阶段，执行顺序：@PreDestroy 注解的销毁动作、实现了 DisposableBean 接口的 Bean 的回调、destroy-method 自定义的销毁方法。这里也有一个销毁前阶段，也属于 Spring 提供的一个扩展点，@PreDestroy 就是基于这个实现的

11. Spring 垃圾收集（GC）

总结：
上面 1、2、3 属于 BeanDefinition 配置元信息阶段，算是 Spring Bean 的前身，想要生成一个 Bean 对象，需要将这个 Bean 的所有信息都定义好；

其中 4、5 属于实例化阶段，想要生成一个 Java Bean 对象，那么肯定需要根据 Bean 的元信息先实例化一个对象；

接下来的 6 属于属性赋值阶段，实例化后的对象还是一个空对象，我们需要根据 Bean 的元信息对该对象的所有属性进行赋值；

后面的 7、8 、9 属于初始化阶段，在 Java Bean 对象生成后，可能需要对这个对象进行相关初始化工作才予以使用；

最后面的 10、11 属于销毁阶段，当 Spring 应用上下文关闭或者主动销毁某个 Bean 时，可能需要对这个对象进行相关销毁工作，最后等待 JVM 进行回收。

Spring 内建的 Bean 作用域有哪些？

spring bean作用域有以下5个：
singleton:单例模式，当spring创建applicationContext容器的时候，spring会欲初始化所有的该作用域实例，加上lazy-init就可以避免预处理；
prototype：原型模式，每次通过getBean获取该bean就会新产生一个实例，创建后spring将不再对其管理；
====下面是在web项目下才用到的===
request：搞web的大家都应该明白request的域了吧，就是每次请求都新产生一个实例，和prototype不同就是创建后，接下来的管理，spring依然在监听
session:每次会话，同上
global session:全局的web域，类似于servlet中的application

AOP

通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。利用AOP可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。
AOP 并没有帮助我们解决任何新的问题，它只是提供了一种更好的办法，能够用更少的工作量来解决现有的一些问题，并且使得系统更加健壮，可维护性更好。同时，它让我们在进行系统架构和模块设计的时候多了新的选择和新的思路。

AOP vs OOP

AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP(面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。

而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。

AOP应用的场景

日志记录，性能统计，安全控制，事务处理，异常处理

AspectJ vs Spring AOP

AOP实现的关键在于 代理模式，AOP代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；动态代理则以Spring AOP为代表。
（1）AspectJ是静态代理的增强，所谓静态代理，就是AOP框架会在编译阶段生成AOP代理类，因此也称为编译时增强，他会在编译阶段将AspectJ(切面)织入到Java字节码中，运行的时候就是增强之后的AOP对象。
（2）Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是每次运行时在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法

动态代理（Dynamic Proxy）

动态代理（Dynamic Proxy）是采用Java的反射技术，在运行时按照某一接口要求创建一个包装了目标对象的新的代理对象，并通过代理对象实现对目标对象的控制操作。

Spring是如何管理事务的

首先，我们知道 Spring 是一个容器，不同的框架在处理事务时用到的对象不同，原生的 JDBC 使用 Connection ，而 Mybatis 中使用 SqlSession 对象。而 Spring 为了整合这些不同的框架，定义了一个 PlatformTransactionManager 接口来统一标准，对不同的框架又有不同的实现类。
在 Spring 中根据 DAO 层技术的不同来选择不同的事务处理的对象，是 JDBC 时使用 DataSourceTransactionManager，是 Hibernate 时使用 HibernateTransitionmanager 对象，核心对象就是 Transitionmanager。
在 Spring 中管理事务会涉及到这几个属性，事务隔离级别、是否只读、事务的传播行为，说到事务的传播行为，指的就是不同的业务方法之间相互调用时，应该如何管理事务

Spring事务传播机制

事务的特性

原子性（Atomicity）：事务是一个原子操作，由一系列动作组成。事务的原子性确保动作要么全部完成，要么完全不起作用。
一致性（Consistency）：一旦事务完成（不管成功还是失败），系统必须确保它所建模的业务处于一致的状态，而不会是部分完成部分失败。在现实中的数据不应该被破坏。
隔离性（Isolation）：可能有许多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。
持久性（Durability）：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，这样就能从任何系统崩溃中恢复过来。通常情况下，事务的结果被写到持久化存储器中。

Spring事务的配置方式

1. 编程式事务管理
   编程式事务管理是侵入性事务管理，使用TransactionTemplate或者直接使用PlatformTransactionManager，对于编程式事务管理，Spring推荐使用TransactionTemplate。

2. 声明式事务管理
   声明式事务管理建立在AOP之上，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。
   编程式事务每次实现都要单独实现，但业务量大功能复杂时，使用编程式事务无疑是痛苦的，而声明式事务不同，声明式事务属于无侵入式，不会影响业务逻辑的实现，只需要在配置文件中做相关的事务规则声明或者通过注解的方式，便可以将事务规则应用到业务逻辑中。
   显然声明式事务管理要优于编程式事务管理，这正是Spring倡导的非侵入式的编程方式。唯一不足的地方就是声明式事务管理的粒度是方法级别，而编程式事务管理是可以到代码块的，但是可以通过提取方法的方式完成声明式事务管理的配置。

事务的传播机制

事务的传播性一般用在事务嵌套的场景，比如一个事务方法里面调用了另外一个事务方法，那么两个方法是各自作为独立的方法提交还是内层的事务合并到外层的事务一起提交，这就是需要事务传播机制的配置来确定怎么样执行。
常用的事务传播机制如下：

PROPAGATION_REQUIRED
Spring默认的传播机制，能满足绝大部分业务需求，如果外层有事务，则当前事务加入到外层事务，一块提交，一块回滚。如果外层没有事务，新建一个事务执行
PROPAGATION_REQUES_NEW
该事务传播机制是每次都会新开启一个事务，同时把外层事务挂起，当当前事务执行完毕，恢复上层事务的执行。如果外层没有事务，执行当前新开启的事务即可
PROPAGATION_SUPPORT
如果外层有事务，则加入外层事务，如果外层没有事务，则直接使用非事务方式执行。完全依赖外层的事务
PROPAGATION_NOT_SUPPORT
该传播机制不支持事务，如果外层存在事务则挂起，执行完当前代码，则恢复外层事务，无论是否异常都不会回滚当前的代码
PROPAGATION_NEVER
该传播机制不支持外层事务，即如果外层有事务就抛出异常
PROPAGATION_MANDATORY
与NEVER相反，如果外层没有事务，则抛出异常
PROPAGATION_NESTED
该传播机制的特点是可以保存状态保存点，当前事务回滚到某一个点，从而避免所有的嵌套事务都回滚，即各自回滚各自的，如果子事务没有把异常吃掉，基本还是会引起全部回滚的。

事务的隔离级别

事务的隔离级别定义一个事务可能受其他并发务活动活动影响的程度，可以把事务的隔离级别想象为这个事务对于事物处理数据的自私程度。

在一个典型的应用程序中，多个事务同时运行，经常会为了完成他们的工作而操作同一个数据。并发虽然是必需的，但是会导致以下问题：

脏读（Dirty read）
脏读发生在一个事务读取了被另一个事务改写但尚未提交的数据时。如果这些改变在稍后被回滚了，那么第一个事务读取的数据就会是无效的。
不可重复读（Nonrepeatable read）
不可重复读发生在一个事务执行相同的查询两次或两次以上，但每次查询结果都不相同时。这通常是由于另一个并发事务在两次查询之间更新了数据。
不可重复读重点在修改。

幻读（Phantom reads）
幻读和不可重复读相似。当一个事务（T1）读取几行记录后，另一个并发事务（T2）插入了一些记录时，幻读就发生了。在后来的查询中，第一个事务（T1）就会发现一些原来没有的额外记录。
幻读重点在新增或删除。

在理想状态下，事务之间将完全隔离，从而可以防止这些问题发生。然而，完全隔离会影响性能，因为隔离经常涉及到锁定在数据库中的记录（甚至有时是锁表）。完全隔离要求事务相互等待来完成工作，会阻碍并发。因此，可以根据业务场景选择不同的隔离级别。

隔离级别 含义
ISOLATION_DEFAULT 使用后端数据库默认的隔离级别
ISOLATION_READ_UNCOMMITTED 允许读取尚未提交的更改。可能导致脏读、幻读或不可重复读。
ISOLATION_READ_COMMITTED （Oracle 默认级别）允许从已经提交的并发事务读取。可防止脏读，但幻读和不可重复读仍可能会发生。
ISOLATION_REPEATABLE_READ （MYSQL默认级别）对相同字段的多次读取的结果是一致的，除非数据被当前事务本身改变。可防止脏读和不可重复读，但幻读仍可能发生。
ISOLATION_SERIALIZABLE 完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻影读。这在所有隔离级别中也是最慢的，因为它通常是通过完全锁定当前事务所涉及的数据表来完成的。

哪些情况下事务会失效

spring事务是通过切面实现的，源码在TransactionInterceptor类中。事务开启依赖数据库链接的，而链接是和线程绑定的。
嵌套事务通过savepoint实现，事务方法中开启新事务则通过获取新的链接进行事务开启（实际就是关闭自动提交）。
链接对象封装在TransactionInfo中，它也记录了前一个事务对象，如果没有则为null。
每开启一个事务，这个事务对象都会绑定到一个ThreadLocal静态变量中，即当前的事务对象。
spring事务切面基于以上逻辑实现了声明式事务管理，及事务属性的传播（在当前存在或不存在事务时，加入当前事务或开启新的事务或以非事务方式执行或在嵌套事务中执行）。

1. 直接new出来的对象添加事务不起作用，因为只有spring定义的bean才接受事务。
   2.由于mysql的引擎用Myisam不支持事务，所以如果使用mysql的myisam引擎的话，事务不起作用。
   3.如果@Transaction注解到非public方法上，事务不起作用，这是因为spring的Aop特性。
   4.如果在当前类中进行内部调用方法，比如在A类中有a方法和b方法，a方法没有加@Transaction，b方法加了@Transaction，在方法a中调用方法b，方法b中的事务也不会生效。这是因为spring在扫描bean的时候会自动为标注了@Transaction注解类生成一个代理类，在有注解方法被调用时，实际上是代理类调用的，代理类在调用之前会开启事务，执行事务操作。但是同类中的方法相互调用，相当于this.b（），此时的b方法并非代理类调用，而是直接通过原有的bean直接调用，所以注解不起作用。
   5.异常类型错误，如果抛出的runtimeException事务才会回滚。
   6.如果异常被catch到，必须要抛出异常，事务才会回滚

简述 Spring 事件机制原理？

Spring 应用上下文就是一个 ApplicationEventPublisher 事件发布器，其内部有一个 ApplicationEventMulticaster 事件广播器（被观察者），里面保存了所有的 ApplicationListener 事件监听器（观察者）。Spring 应用上下文发布一个事件后会通过 ApplicationEventMulticaster 事件广播器进行广播，能够处理该事件类型的 ApplicationListener 事件监听器则进行处理。

Spring 内建的事件：
ContextRefreshedEvent：Spring 应用上下文就绪事件
ContextStartedEvent：Spring 应用上下文启动事件
ContextStoppedEvent：Spring 应用上下文停止事件
ContextClosedEvent：Spring 应用上下文关闭事件

Spring 应用上下文的生命周期

Spring 应用上下文就是 ApplicationContext，生命周期主要体现在 org.springframework.context.support.AbstractApplicationContext#refresh() 方法中，大致如下：

1. Spring 应用上下文启动准备阶段，设置相关属性，例如启动时间、状态标识、Environment 对象
2. BeanFactory 初始化阶段，初始化一个 BeanFactory 对象，加载出 BeanDefinition 们；设置相关组件，例如 ClassLoader 类加载器、表达式语言处理器、属性编辑器，并添加几个 BeanPostProcessor 处理器
3. BeanFactory 后置处理阶段，主要是执行 BeanFactoryPostProcessor 和 BeanDefinitionRegistryPostProcessor 的处理，对 BeanFactory 和 BeanDefinitionRegistry 进行后置处理，这里属于 Spring 应用上下文的一个扩展点
4. BeanFactory 注册 BeanPostProcessor 阶段，主要初始化 BeanPostProcessor 类型的 Bean（依赖查找），在 Spring Bean 生命周期的许多节点都能见到该类型的处理器
5. 初始化内建 Bean，初始化当前 Spring 应用上下文的 MessageSource 对象（国际化文案相关）、ApplicationEventMulticaster 事件广播器对象、ThemeSource 对象
6. Spring 事件监听器注册阶段，主要获取到所有的 ApplicationListener 事件监听器进行注册，并广播早期事件
7. BeanFactory 初始化完成阶段，主要是初始化所有还未初始化的 Bean（不是抽象、单例模式、不是懒加载方式）
8. Spring 应用上下文刷新完成阶段，清除当前 Spring 应用上下文中的缓存，例如通过 ASM（Java 字节码操作和分析框架）扫描出来的元数据，并发布上下文刷新事件
9. Spring 应用上下文启动阶段，需要主动调用 AbstractApplicationContext#start() 方法，会调用所有 Lifecycle 的 start() 方法，最后会发布上下文启动事件
10. Spring 应用上下文停止阶段，需要主动调用 AbstractApplicationContext#stop() 方法，会调用所有 Lifecycle 的 stop() 方法，最后会发布上下文停止事件
11. Spring 应用上下文关闭阶段，发布当前 Spring 应用上下文关闭事件，销毁所有的单例 Bean，关闭底层 BeanFactory 容器；注意这里会有一个钩子函数（Spring 向 JVM 注册的一个关闭当前 Spring 应用上下文的线程），当 JVM “关闭” 时，会触发这个线程的运行
    总结：

上面的 1、2、3、4、5、6、7、8 都属于 Sping 应用上下文的刷新阶段，完成了 Spring 应用上下文一系列的初始化工作；
9 属于 Spring 应用上下文启动阶段，和 Lifecycle 生命周期对象相关，会调用这些对象的 start() 方法，最后发布上下文启动事件；
10 属于 Spring 应用上下文停止阶段，和 Lifecycle 生命周期对象相关，会调用这些对象的 stop() 方法，最后发布上下文停止事件；
11 属于 Spring 应用上下文关闭阶段，发布上下文关闭事件，销毁所有的单例 Bean，关闭底层 BeanFactory 容器。

BeanFactory 则是 Spring 底层 IoC 容器，里面保存了所有的单例 Bean，ObjectFactory 和 FactoryBean 自身不具备依赖查找的能力，能力由 BeanFactory 输出。

（1）构建 BeanFactory，以便于产生所需的“演员”。（2）注册可能感兴趣的事件。 （3）创建 Bean 实例对象。（4）触发被监听的事件。

ObjectFactory、FactoryBean 和 BeanFactory 的区别？

根据其名称可以知道其字面意思分别是：对象工厂，工厂 Bean，Bean工厂
ObjectFactory、FactoryBean 和 BeanFactory 均提供依赖查找的能力。
ObjectFactory 提供的是延迟依赖查找，想要获取某一类型的 Bean，需要调用其 getObject() 方法才能依赖查找到目标 Bean 对象。ObjectFactory 就是一个对象工厂，想要获取该类型的对象，需要调用其 getObject() 方法生产一个对象。
FactoryBean 不提供延迟性，在被依赖注入或依赖查找时，得到的就是通过 getObject() 方法拿到的实际对象。FactoryBean 关联着某个 Bean，可以说在 Spring 中它就是某个 Bean 对象，无需我们主动去调用 getObject() 方法，如果想要获取 FactoryBean 本身这个对象，在 beanName 前面添加 & 即可获取。

DispatcherServlet初始化流程

简单总结起来，Tomcat 容器启动并加载 DispatcherServlet 时所做的主要工作如下：

1. 调用 DispatcherServlet 的构造器（当然也会调用父类的构造器，不过构造器默认实现为空；这个动作很短，基本上可以忽略）
2. 调用 GenericServlet 的 init() 方法，不过，这被 HttpServletBean 重写了；同时，重写的 HttpServletBean 的 init() 方法调用了 initServletBean() 方法；而 initServletBean() 方法会完成以下操作：
   a. 初始化（创建）一个 WebApplicationContext（实际上是 WebApplicationContext 类）
   b. 调用 AbstractApplicationContext 的 refresh() 方法，完成 BeanFactory创建、读取 SpringMVC 配置文件内容、处理容器后处理器、初始化MessageResource、注册监听器等工作
   c. 通过上一步中读取到的内容，初始化 HandlerMapping & HandlerAdapter 等工作
   ==上面3个步骤才是重要内容==

总的来说，DispatcherServlet 还是一个 Servlet，遵循 constructor() --> init() --> service() --> destroy() 方法的调用流程。只不过，它的这个 init() 方法确实比较复杂

Spring如何解决循环依赖的

Spring通过三级缓存解决了循环依赖，其中一级缓存为单例池（singletonObjects），二级缓存为早期曝光对象earlySingletonObjects，三级缓存为早期曝光对象工厂（singletonFactories）。

当A、B两个类发生循环引用时，在A完成实例化后，就使用实例化后的对象去创建一个对象工厂，添加到三级缓存中，如果A被AOP代理，那么通过这个工厂获取到的就是A代理后的对象，如果A没有被AOP代理，那么这个工厂获取到的就是A实例化的对象。

当A进行属性注入时，会去创建B，同时B又依赖了A，所以创建B的同时又会去调用getBean(a)来获取需要的依赖，此时的getBean(a)会从缓存中获取：

第一步：先获取到三级缓存中的工厂；第二步：调用对象工工厂的getObject方法来获取到对应的对象，得到这个对象后将其注入到B中。紧接着B会走完它的生命周期流程，包括初始化、后置处理器等。第三步：当B创建完后，会将B再注入到A中，此时A再完成它的整个生命周期。至此，循环依赖结束！

为什么要使用三级缓存呢？二级缓存能解决循环依赖吗？

如果要使用二级缓存解决循环依赖，意味着所有Bean在实例化后就要完成AOP代理，这样违背了Spring设计的原则，Spring在设计之初就是通过AnnotationAwareAspectJAutoProxyCreator这个后置处理器来在Bean生命周期的最后一步来完成AOP代理，而不是在实例化后就立马进行AOP代理。

Spring 中几种初始化方法的执行顺序？

有以下初始化方式：
Aware 接口：实现了 Spring 提供的相关 XxxAware 接口，例如 BeanNameAware、ApplicationContextAware，其 setXxx 方法会被回调，可以注入相关对象
@PostConstruct 注解：该注解是 JSR-250 的标准注解，Spring 会调用该注解标注的方法
InitializingBean 接口：实现了该接口，Spring 会调用其 afterPropertiesSet() 方法
自定义初始化方法：通过 init-method 指定的方法会被调用
在 Spring 初始 Bean 的过程中上面的初始化方式的执行顺序如下：

Aware 接口的回调
JSR-250 @PostConstruct 标注的方法的调用
InitializingBean#afterPropertiesSet 方法的回调
init-method 初始化方法的调用

Spring Mvc

SpringMVC是一种基于Java，实现了Web MVC设计模式，请求驱动类型的轻量级Web框架，即使用了MVC架构模式的思想，将Web层进行职责解耦。基于请求驱动指的就是使用请求-响应模型，框架的目的就是帮助我们简化开发，SpringMVC也是要简化我们日常Web开发。

Spring Mvc核心架构

Spring Mvc核心架构

（1）用户发送请求至前端控制器DispatcherServlet；
（2） DispatcherServlet收到请求后，调用HandlerMapping处理器映射器，请求获取Handle；
（3）处理器映射器根据请求url找到具体的处理器，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet；
（4）DispatcherServlet通过HandlerAdapter处理器适配器调用处理器；
（5）执行处理器(Handler，也叫后端控制器)；
（6）Handler执行完成返回ModelAndView；
（7）HandlerAdapter将Handler执行结果ModelAndView返回给DispatcherServlet；
（8）DispatcherServlet将ModelAndView传给ViewResolver视图解析器进行解析；
（9）ViewResolver解析后返回具体View；
（10）DispatcherServlet对View进行渲染视图（即将模型数据填充至视图中）
（11）DispatcherServlet响应用户。

Spring MVC的主要组件？

（1）前端控制器 DispatcherServlet（不需要程序员开发）
作用：接收请求、响应结果 相当于转发器，有了DispatcherServlet 就减少了其它组件之间的耦合度。
（2）处理器映射器HandlerMapping（不需要程序员开发）
作用：根据请求的URL来查找Handler
（3）处理器适配器HandlerAdapter
注意：在编写Handler的时候要按照HandlerAdapter要求的规则去编写，这样适配器HandlerAdapter才可以正确的去执行Handler。
（4）处理器Handler（需要程序员开发）
（5）视图解析器 ViewResolver（不需要程序员开发）
作用：进行视图的解析 根据视图逻辑名解析成真正的视图（view）
（6）视图View（需要程序员开发jsp）
View是一个接口， 它的实现类支持不同的视图类型（jsp，freemarker，pdf等等）

Spring MVC的异常处理 ？

可以将异常抛给Spring框架，由Spring框架来处理；我们只需要配置简单的异常处理器，在异常处理器中添视图页面即可。