一旦Controller控制器类向SpringMVC 框架进行了注册，SpringMVC 框架就会管理Controller对象的生命周期。
默认情况下，Controller对象的存在范围为singleton（单例），即在整个应用程序的生命周期内，一个Controller类只有一个实例。
singleton范围的优点是节省内存空间，但是也存在以下两个缺点：
（1）当大量客户请求同时访问一个Controller对象的共享数据时，容易造成并发问题。
（2） 如果一个Controller对象采用了线程同步机制，那么当大量客户请求同时访问这个Controller对象时，会导致部分处理客户请求的线程阻塞，影响Web应用的并发性能。
为了克服以上缺点，SpringMVC 框架还允许把一个Controller对象的存在范围设置为request或session：
（1）request范围：对于每一个HTTP请求，Spring MVC框架创建一个Controller对象。当完成了对这个HTTP请求的响应，Controller对象就结束生命周期。
（2）session范围：对于每一个HTTP会话，Spring MVC框架创建一个Controller对象。当这个HTTP会话结束，Controller对象就结束生命周期。
在以下代码中，ControllerA和ControllerB分别使用了@RequestScope和@SessionScope注解，它们的范围分别为request和session：
@Controller
@RequestScope //ControllerA的存在范围为request
public class ControllerA{}
@Controller
@SessionScope //ControllerB的存在范围为session
public class ControllerB{}
以上@RequestScope注解等价于@Scope("request")；@SessionScope注解等价于@Scope("session")。
除了request和session范围，还可以把Controller对象的存在范围设为application，这意味着在整个Web应用的生命周期内，只有一个Controller对象，例如：
@Controller
@ApplicationScope //等价于：@Scope("application")
public class ControllerA{}
SpringMVC初写（三）Controller的生命周期
Spring框架默认创建的对象的方式是单例，所以业务控制器Controller也是一个单例对象
由此可证明，无论是同一次请求还是同一次会话和不同请求它的对象都是相同的
然而由于对象是单例的，随之而来的产生了两个问题：
- 请求数据如果放在成员变量上面，会相互影响。
- 在处理请求比较多的时候，请求使用同一个对象处理，会导致阻塞
SpringMVC提供了request，session两个生命周期处理上述的问题
request：每次新的请求，创建一个实例
session：每次会话创建一个新的实例，就是同一个浏览器，就使用同一个实例
每个请求创建一个实例，类似多例“prototype”
由于每次请求都会产生新的对象，对内存的消耗比较大一般不推荐使用
每次会话（Session），创建一个实例
相同浏览器访问默认为同一个会话（Session）